On Feb 12, 10:30 am, "JP" <[EMAIL PROTECTED]> wrote: > > But It would be nice to be able to have total control over the > transactional state of the connection, so that when I know that I'm > just doing a select or two I don't have to have the overhead of a > BEGIN that I know is useless, but as things stand I can't do that, > because do_begin isn't implemented for any of the dialects. I guess > that's because sqlalchemy is depending on the underlying DBAPI > implementation to handle sending BEGIN statements before the first > query that is outside of a transaction?
DBAPI, including psycopg2, has no begin() method; there is only rollback() and commit(). like the example illustrates, there is no BEGIN being issued for every SELECT statement when using psycopg2 in non-autocommit mode, which applies to SQLAlchemy as well. therefore there is no performance bottleneck; this is a django issue only. > > I noticed a TODO about implementing true autocommit behavior, which is > what I need -- a way to tell the dbapi module *not* to start those > implicit transactions. it doesnt. run the example - no implicit transaction beyond the initial connection (which is required, since it must implement rollback() and commit()). SA has been doing its own autocommit on top of non-autocommitting connections since the 0.2 series at least. running in "non-auto-commit" mode is standard practice for databases like oracle. theres always a transaction in place. but its not started for every select statement. only at connection time and after each rollback or commit. --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
