On Jul 24, 2010, at 2:33 AM, avdd wrote: > I rely heavily on the version_id_col feature and I would like to be > able to either explicitly increment the version, or have the version > incremented when a relationship changes. The issue here is that a > change in a relationship is a semantic change to the parent record and > should conflict with other changes to the record. > > For example consider a timesheet record with a set of allowances and > an approved flag. An administrator may approve a timesheet based on > the given allowances, but without extra locking there is a race > condition where the allowances could be updated between the > administrator viewing the timesheet and approving it.
so, thoughts on version_id_col, here is where it came from: http://docs.jboss.org/hibernate/stable/core/reference/en/html/mapping.html#mapping-declaration-version its one of the few SQLA features left that we copied directly from hibernate before we actually had a use for it. The main thing you get with version_id_col, as opposed to just using Column() with an on_update() expression or a mapper extension, is that SQLA uses version_id_col in the WHERE clause for the UPDATE. These days, with a default session configuration, its pretty hard to get a conflict since transaction isolation combined with expire_on_commit=True makes it impossible to have stale data in memory. right now version_id_col is pretty hardwired to only increment when another column attribute on the object has changed, and it wont respond to bumping it up manually (i.e. that wont register ultimately as an UPDATE-worthy change). We should probably make enhancements in this area, if history is detected, then just consider it a new value to be used and issue the UPDATE. As for detecting the relationship change, a change to the related collection should land the parent object into the before_update() hook where you would bump the version_id there. But for the moment only hacks like, bumping up some other column on the object to be changed, or doing some manual work in before_update() or after_update(), would suit this. Otherwise the _save_obj() logic simply wont listen to what you're doing to version_id_col. There's a patch at http://www.sqlalchemy.org/trac/ticket/1857 that would probably allow this to proceed, pending further tests. Since it is a one liner it looks like it could likely get into 0.6.4. Or you could implement version_id_col without using the actual feature, using a recipe like that of examples/versioning/history_meta.py . My own versioning needs usually require session level extensions. > > Doable? > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/sqlalchemy?hl=en. > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
