On Jun 29, 2010, at 11:07 AM, Chris Withers wrote: > Michael Bayer wrote: >>> Specifically, the following: >>> >>> - change the primary key of the instance by deleting it so that the >>> dataabse assigns a new primary key? >> that wont work. you need to take the object and call make_transient() on >> it, re-add it to the session. > > Where is make_transient documented? (failing that, where do I import it from?)
whoops http://www.sqlalchemy.org/docs/reference/orm/sessions.html?highlight=make_transient#sqlalchemy.orm.make_transient > > > the latest you could do this would be sessionextension.before_flush(). > > How do I know what instances I need to worry about in before_flush? you need to scan. see the versioning example. > http://www.sqlalchemy.org/docs/05/reference/orm/interfaces.html#sqlalchemy.orm.interfaces.SessionExtension.before_flush > implies is `instances` list passed can't be relied upon... "instances" is a deprecated thing that will always be empty unless you're actually using that feature which I'm pretty sure you're not. > >>> - do a query to update an existing row? (where would I get the session >>> from?) >> you can do that, if you use the given connection. session is from >> object_session(instance). > > So the session returned by object_session will always be connected to the > connection provided in the `connection` parameter? you can deduce this from the fact that the object passed is part of the current session, and the flush occurs in one transaction/connection which is itself owned by that session, so yes. > >>> - change the row the instance corresponds to and somewhow return a "new >>> replacement instance"? >> not sure what that means > > That's this bit from my previous example: > > >>> session.add(x) > >>> session.commit() > >>> x.id, x.name, x.value, x.valid_from, x.valid_to > 1, 'foo', 100, 2010-06-29 09:00, None > > >>> x.value = 200 > >>> session.commit() > >>> x.id, x.name, x.value, x.valid_from, x.valid_to > 2, 'foo', 200, 2010-06-29 09:05, None > > >>> 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 > > - only primary objects in one table that's not what your example above illustrates.... > - 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 > - only certain column changes cause a new version to be created (eg: if the > 'notes' column changes, we don't want to create a new version; would > session.is_modified() still help with that?) using the recipe I linked, you'd add some logic into before_flush() that does attributes.get_history(x, 'foo') for each attribute that you care about, instead of using session.is_modified() which is across the board -- 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.
