On Aug 10, 2007, at 8:32 AM, Grzegorz Adam Hankiewicz wrote:
> > Is there any documentation about this or do sqlalchemy applications > deal > with concurrent writes in another way? If the unit of work tracked > those > internal version numbers the flushing would fail and an exception > raised, but I haven't seen anything about this in the docs so far. > HI Grzegorz: SQLAlchemy has always supported this feature using the "version_id_col" keyword argument to mapper(), which is described at: http://www.sqlalchemy.org/docs/04/ sqlalchemy_orm.html#docstrings_sqlalchemy.orm_modfunc_mapper the "versioning" pattern here should probably receive a full-fledged example in the mappers.html document, however. Even if you dont have a version_id_col set up, SQLAlchemy will still check the updated rowcount on UPDATE and DELETE that it matches the expected results. an example from the unit tests looks something like: version_table = Table('version_test', MetaData(testbase.db), Column('id', Integer, Sequence('version_test_seq'), primary_key=True ), Column('version_id', Integer, nullable=False), Column('value', String(40), nullable=False) ) class Foo(object):pass mapper(Foo, version_table, version_id_col=version_table.c.version_id) When an UPDATE or DELETE cannot locate the row with the correct version ID, a sqlalchemy.exceptions.ConcurrentModificationError is thrown and the transaction is rolled back. Hope this helps, - mike --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
