On Apr 30, 2012, at 1:08 AM, Dan Callaghan wrote: > > Shouldn't calling .append() or any other method on an expired > relationship list at least raise an exception, given that the list has > been discarded?
> Could SQLAlchemy expire the relationship list without actually replacing > the list instance? This is certainly a case I've never seen before. The collection internals currently don't try to prevent collections from being used once they are no longer associated with a parent. This wouldn't really work generically, as it's entirely valid to replace a collection with another, then continue appending to the detached collection. Most of the avenues that were at first apparent here fall under the category of a post-detach append being disallowed or otherwise warning. There's an inconsistency regarding when a collection is replaced with another (it's explicitly unlinked from the internal CollectionAdapter which maintains ORM events, so that it no longer generates events), versus when the collection is expired and just discarded (nothing is done, the CollectionAdapter remains and essentially passes invalid events if the collection continues to be used). But really here we're talking about a third state - the collection is still associated with its CollectionAdapter, and the CollectionAdapter is in some kind of "illegal to use" state. Meaning the above inconsistency is really not inconsistent at all, it's just a three-state system - linked, unlinked, and invalid. The "empty the list" case is probably not possible at all without major backwards-incompatible changes. SQLAlchemy indicates an attribute as "expired" by the fact that the attribute's key is no longer in obj.__dict__. With no value present, this expiration case indicates that a new collection should be loaded on next access from the database. Another chief concern when attempting to change this behavior is one of latency. Expiration and append events both occur in large numbers, so any function calls added to these adds palpable latency. The "invalidate-on-expire" use case is at ticket http://www.sqlalchemy.org/trac/ticket/2476 and is organized for the "three-state" idea, and shouldn't add latency in most cases. This is for 0.8 only. > > Is there some other way we could avoid this kind of problem? Personally I never use the begin_nested()/check/rollback pattern, it's messy and does a lot of work. commit() and rollback() have network, database, and in-python overhead, Python raising exceptions has lots of overhead, running a flush() and generating an INSERT that's thrown away has lots of overhead. The way this method is structured, it's guaranteed to be quite slow whether or not the object exists. The expiration that commit/rollback does is very expensive to subsequent operations too; in 0.8 we have improved this so that only objects that were actually made dirty within the begin_nested() are expired, but until then if you have expire_on_commit enabled you'll be seeing everything else in the session reloading itself on next access after each of these append() operations. I always use recipes that involve loading the object first, either individually or by populating a collection up front before a large sequence of operations. A simple recipe that I often use (or a variant) is UniqueObject: http://www.sqlalchemy.org/trac/wiki/UsageRecipes/UniqueObject -- 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.
