On Feb 3, 2014, at 2:39 AM, Wolfgang Schnerring <w...@gocept.com> wrote:
> > I guess I didn't make it clear enough that I'm talking mainly about > this collections issue. Sorry about that; let me try again: > I feel it would be much more convenient if the state achieved by a savepoint > was reflected by collection properties (basically like a real commit), but I > don't know whether a) that fits sqlalchemy's usage concept and b) there are > adverse performance implications. > > Does that make more sense? If not I guess I should work up a concrete > code example. I’m sensing the usual collection based use cases like, you want to call session.delete(obj) and have it removed from collections (use delete-orphan instead), or you’re manipulating foreign keys directly and wishing that updates collections (either don’t do it that way, or use events, see http://www.sqlalchemy.org/trac/wiki/UsageRecipes/ExpireRelationshipOnFKChange for an example), but that these points would be at the boundaries of savepoints, particularly the beginning of a savepoint, isn’t resonating with me just yet. So a real example illustrating an unexpected result would be best. Also note that the begin/rollback events are very easy to augment with other actions, you can add expire_all steps using events like after_transaction_create() and after_transaction_end().
signature.asc
Description: Message signed with OpenPGP using GPGMail
