On Saturday, April 26, 2014 9:12:22 PM UTC+1, Michael Bayer wrote: > > On Apr 26, 2014, at 3:26 PM, Tim Kersten <t...@io41.com <javascript:>> > 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
Cool, thanks. > > > 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?) > Are you saying there's a way to use the ORM with repeatable read isolation without potentially overwriting another user's changes? I'm not sure how (other than using version col id, in which case I don't need to use repeatable read isolation). > > 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”. > Timestamps are only so granular though (depending on the database used) - two updates in very close succession may have the same timestamp set, so while it's unlikely to lead to data loss, it cannot guarantee it like a plain counter version column would. > > > 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're right, an ORM is meant to target a specific entity. Whether the failure is silent or not doesn't play much role, in fact as you pointed out earlier it makes a lot of sense in an ORM for a failed update to raise an exception. -- 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.
