On Apr 26, 2014, at 3:26 PM, Tim Kersten <t...@io41.com> wrote: > The resulting behaviour would be identical to using a version col id, but > only for this transaction and the instance passed to the update_where() > method, and instead of "UPDATE ... WHERE <pk> = %s AND version = %s" you'd > have "UPDATE ... WHERE <pk> = %s AND name = %s".
This is where it would have to go: https://bitbucket.org/zzzeek/sqlalchemy/src/146fbf6d26a8c4140a47aeb03131fdf81007b9a2/lib/sqlalchemy/orm/persistence.py?at=master#cl-308 where you can see that logic is wired to a single "expression", which could be a SQL expression that gathers up lots of columns, but the expression is fixed. It isn't derivable from all the attributes that have "changed", and the logic here would need to be expanded into a much more elaborate, complicated, and non-performant system to support this case. For a feature to be added, it must attain a certain ratio of "impact on complexity" to "how many people will actually use it". If the feature is very simple and non-intrusive, we can often add it even if only one person needs it. If the feature is very complex, we can add it only if this is an obvious need by a significant percentage of users. in many cases we add event hooks in areas that are to allow expansion of capabilities, but in the case of "persistence", we already have before_update() and after_update(), adding more hooks into the construction of the actual SQL would be very complex and extremely specific to the mechanics; it would be brittle, unstable and difficult to use. IMHO the two existing approaches have no downsides: 1. repeatable read isolation (which can be set on a per-session or per-transaction basis. Why not just use it?) 2. version columns, including version columns that can be *timestamps*. There is no need to go through an expensive (think TEXT/BLOB columns) and error prone (think floating points) comparison of every column if the UPDATE of a stale row is to be avoided - "stale" just means "our timestamp of the row is earlier than the timestamp that's present". > Advantages of using the above approach instead of version col id: > - Much finer grain changes possible without raising an exception, The behavior where version misses are to be ignored is also quite unusual and I've never known anyone to want silent failure of an UPDATE statement like that. An entity update has a specific intent which is to target that entity; this is at the core of what an ORM is trying to do. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
