Sqlite3ObjectMover(database_driver, options, runner=None, version_detector=None, batcher_factory=<class 'relstorage.adapters.sqlite.batch.Sqlite3RowBatcher'>)¶
database_driver – The IDBDriver in use.
Create the temporary table for storing objects
store_tempsis using an upsert query and simply calls that method.
The same comments apply. In particular, MySQLclient won’t optimize an UPDATE in the same way it does an INSERT.
Uses the cursor’s
executemanymethod to store temporary objects.
If there is a more optimal way to implement putting objects in the database, please do so.
executemanyis implemnted in a C looping over the provided iterator. Which it turns out is exactly what the normal
executemethod also does (it just uses a one-row iterator). So
executemanythat saves substantial setup overhead dealing with sqlite’s prepared statements.
On Postgresql, we use COPY for this (unless we’re using the ‘gevent psycopg2’ driver; it’s the only thing that doesn’t support COPY). None of the supported PostgreSQL drivers have a good
executemanymethod, so they should fall back to using our own RowBatcher.
On Oracle, we use the RowBatcher with a combination of bulk array operations and direct inserts.
On MySQL, the preferred driver (mysqlclient) has a decent implementation of executemany for INSERT or REPLACE (basically an optimized form of what our RowBatcher does). That implementation is shared with PyMySQL as well, but it must be a simple INSERT statement matching a regular expression. Note that it has a bug though: it can’t handle an iterator that’s empty.