On Jun 29, 2010, at 6:27 PM, Chris Withers wrote: > Michael Bayer wrote: >>>>>> for thing in session.query(MyThing).all(): >>> ... print x.id, x.name, x.value, x.valid_from, x.valid_to >>> 1, 'foo', 100, 2010-06-29 09:00, 2010-06-29 09:05 >>> 2, 'foo', 200, 2010-06-29 09:05, None >>> >>> `x` used to correspond to the row with id of 1, but now corresponds to the >>> row with the id of 2. That's the effect I'm looking to achieve. >> I've added that recipe here >> http://www.sqlalchemy.org/trac/wiki/UsageRecipes/VersionedRows > > Sweet. A few questions: > > - why do we need to refresh self.id in case it has expired? Doesn't the very > next line(s) get rid of self.id?
saying self.id = None attempts to load the old value (this is specific to primary key attributes). what would be nicer would be if we could just expire() it, then make_transient(). make_transient() however seems like it should make sure it unexpires expired attributes on the state, which it isn't doing - it causes a recursion overflow at the moment. > > - if the implementation of new_version was generic, I'm guessing we could > live without the mixin? sure why not > > - I take it there are no problems with specifying multiple extensions to > sessionmaker? (we need zope.sqlalchemy's extension too) What effect does > order of extensions have? calls them in order > > - why do we ignore instance states without an identity in before_flush? My own application extends new_version() in one case to also make "transient" a collection of versionable objects attached to the versioned parent. So those objects may be present in "dirty" when we first iterate, but when we get to it, its no longer there. > >>> - only primary objects in one table >> that's not what your example above illustrates.... > > Well, I guess I meant there's only one table for each mapped class and > there's only one active row per instance in the table at any one time. > (I'd like to validate the latter, since users will be able to optionally set > valid_from and valid_to; is before_flush the right place? Is session.query > legit to use there? What exceptions are legit to raise from within > before_flush to indicate validation failure?) before_flush() is great because you can do anything you need. there's no particular restriction on exceptions to raise. > >>> - the valid_from and valid_to form a linked list of version validity >> using the recipe I linked, you'd establish that linkage in the new_version() >> method > > Okay, and I guess I can use attributes.get_history(instance,'valid_from') and > attributes.get_history(instance,'valid_to') to see if these attributes have > been explicitly set? > > Where is the History record returned by get_history documented? eh, it returns a tuple (added, unchanged, deleted). We should make a link to "History" there (its a tuple subclass). -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@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.
