I’m using a cookiecutter-based Pyramid+zope.sqlalchemy+SQLAlchemy stack.  More 
and more lately I’ve been skipping the ORM and using Core for write operations, 
and I frequently run into issues where I forget to mark_changed and 
zope.sqlalchemy ROLLBACKs by default:

> By default, zope.sqlalchemy puts sessions in an ‘active’ state when they are 
> first used. ORM write operations automatically move the session into a 
> ‘changed’ state. This avoids unnecessary database commits. Sometimes it is 
> necessary to interact with the database directly through SQL. It is not 
> possible to guess whether such an operation is a read or a write. Therefore 
> we must manually mark the session as changed when manual SQL statements write 
> to the DB.


The docs go on to describe how I can change the behavior to COMMIT by default:

> If this is a problem you may register the events and tell them to place the 
> session in the ‘changed’ state initially.


My question:  Is there any downside to COMMITing by default?  I assume there’s 
a good reason why the default is to ROLLBACK.  I’m using PostgreSQL, but I’d be 
interested in hearing about how this affects RDBMSs too.

— Theron



-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/598CAFEC-A22F-47E1-8AFE-7B06F29EC5CF%40luhn.com.

Reply via email to