On Nov 11, 2011, at 8:50 AM, Mariano Mara wrote: > On 11.11.11 08:22, Mark Erbaugh wrote: >> Is there a best practice or recipe for handling database concurrency when >> using SQLAlchemy with Pyramid? >> >> I'm considering porting a desktop accounting application to the web with >> Pyramid/SQLAlchemy. Assume that a user opens an invoice for editing. Assume >> that before this user POSTs the changes, another user opens the same invoice >> and posts changes. While with 'desktop' SQLAlchemy, the update is protected >> by a database transaction, I don't think that's true on the web. >> >> Here's my first thought of a possible solution. Assume the invoice is >> represented by a one-many relationship between a header and detail table. >> There could be a write count field in the header that is automatically >> incremented every time the invoice is updated. This write count could be >> saved in a hidden field (or in the user's session). When the inovice is >> POSTed, the write count field could be compared with the write count in the >> database and an error issued if they don't match. >> >> Are there any problems with this approach, or is there a better solution? >> >> Thanks, >> Mark >> > > The classic lost update trick. Take a look at version_id_col in the mapper > creation [1] > > > [1]http://www.sqlalchemy.org/docs/orm/mapper_config.html?highlight=version_id_col
Yes, that's (lost update) what it is. Thanks for the version_id_col pointer. That pretty much encapsulates what I was proposing, but handles it automaticaly in SQLAlchemy. Mark -- You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en.
