On 02/03/2016 11:10 PM, James Emerton wrote:
im not sure why you need to use begin() at all? in autocommit mode, the user
presses save, you just call flush(). flush() always uses a transaction
internally. That's originally how the Session was meant to be used, having an
explicitly open transaction was an optional feature.
Unfortunately, some processes in our application execute SQL directly, often
operating on records which were very recently inserted into the database. Our
models have save methods that validate the record and then issue a flush. This
means that flush will be called several times during the course of a
transaction. (Yay legacy code!)
Since you're looking for an ORM that can rollback a transaction and
simultaneously reset the state of the objects to exactly what they were at the
beginning of that transaction, there is no ORM I'm aware of that can do this
any differently than SQLAlchemy does. More simplistic ORMs like Django /
Peewee etc. have no concept of expiration-on-rollback, and after a transaction
rollback your objects have exactly the same in-memory state as before.
SQLAlchemy offers this mode of operation both through the
_enable_transaction_accounting=False (with small bugfixes apparently) as well
as the use of an external transaction.
The only requirement is that attributes and instances that were dirty before
the transaction began must be dirty after a rollback.
I’m not concerned about instance attributes being rolled back to their
previous value (we didn’t have this before.)
If we use _enable_transaction_accounting=False and issue multiple calls
to flush during the course of a transaction is
there a way to restore the dirty state to the point before the
transaction began?
there are two things that are possible. not touching the object's
attributes at all, in which case they have at all times whatever you
last put into them, or there is expiring them completely and restoring
whatever is in the database at the moment. There is no ability to
reset in-memory state to some previous snapshot.
You might find it a better approach overall to use a separate Session
for persistence, have your users deal with entirely detached objects and
then just copy their state to the Session when you're ready to persist
them, using merge() or something homegrown.
Thanks,
James
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at https://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
