On 11/28/2012 06:32 PM, Michael Bayer wrote: > >> We are using it for a third reason: >> >> If highly concurrent reads are desired against the SQLite >> database, it is advised that the autoflush feature be disabled, >> and potentially even that autocommit be re-enabled, which has the >> effect of each SQL statement and flush committing changes >> immediately. >> > > OK, I'd set this on the SQLite connection itself using the > "autocommit" > option: http://docs.python.org/2/library/sqlite3.html#controlling-transactions > basically setting isolation_level=None. You can do this in > connect_args to create_engine() or in a pool "on connect" event. I'd > keep the Session in "autocommit=False", and still have the app run > using "commit" as a signal that "we're done with the work we're > doing". that doc should be improved. AFAICT this will mean we have absolutely no transactional behaviour but each flush will automatically make it to the database. Unfortunately some of our operations require the transaction boundary to be able to roll back if there is for example a permission issue.
Thanks for the pointer though - we will first switch to autocommit=False and adjust our code. Greetings, Torsten -- DYNAmore Gesellschaft fuer Ingenieurdienstleistungen mbH Torsten Landschoff Office Dresden Tel: +49-(0)351-4519587 Fax: +49-(0)351-4519561 mailto:torsten.landsch...@dynamore.de http://www.dynamore.de Registration court: Mannheim, HRB: 109659, based in Karlsruhe, Managing director: Prof. Dr. K. Schweizerhof, Dipl.-Math. U. Franz -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
