On Jan 31, 2010, at 2:25 AM, avdd wrote: > Something a bit more normal now. > > Combining optimistic concurrency control with cascading PK updates is > problematic, if you load the child relation, the session issues > unecessary updates for the children, resulting in > ConcurrentModificationError
There is a mapper issue here, but even when it is fixed, the version_id_col mechanism can't work consistently in any case - for passive updates, version_id_col wouldn't be incremented, for in-memory objects, it is. Anyway this is an elaborate issue which might require significant effort to resolve, so I wouldn't count on it for now. its ticket #1671, similar but not quite the same as #1362. The mapper needs to know to look at the "new" value of the PK col, not the "old" one, in the case that a passive update is known to have changed it on the DB side already. Usually it looks at the "old" value assuming it needs to issue the UPDATE. These are the only two issues known to exist with mutable primary keys, if that helps. -- 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.
