On Jul 2, 2006, at 4:05 AM, Tzahi Fadida wrote: > > The documentation says: "As far as the issue of the same object > being modified > in two different Sessions, that's an issue of concurrency detection; > SQLAlchemy does some basic concurrency checks when saving objects, > with the > option for a stronger check using version ids. See None for more > details." >
oops, "version_id_col": http://www.sqlalchemy.org/docs/ adv_datamapping.myt#advdatamapping_arguments > Using ORM of course: > I don't want an object such as "query.get(2)" in two different > threads in two > different sessions to be changed if one of them changes. > Especially when transactions are in use. > I.e. two different threads are for two different people who are > oblivious to > each other and if there is a conflict, one of their transactions > will be > rejected. I tried it and it seems ok, but if it is a planned > feature i wish > to know about it. earlier versions of SQLAlchemy enforced that session activity was always performed in a thread-local manner...meaning the session was "implicit" and would always be an instance local to the current thread. to get "implicitly threadlocal" behavior in your application, its most directly accomplished by using the SessionContext extension: http://www.sqlalchemy.org/docs/plugins.myt#plugins_sessioncontext SessionContext is also used for a more "automatic" style of thread local behavior that mimics that of earlier versions of SA, which is called "threadlocal": http://www.sqlalchemy.org/docs/plugins.myt#plugins_threadlocal however, if you just create your own sessions using create_session() and use them in only local contexts, then there will also not be any interaction between threads. > > Also, is it possible to do: > * SAVEPOINT as in PostgreSQL. > http://www.postgresql.org/docs/current/static/sql-savepoint.html theres no built-in support for this right now; you could try using raw SQL via connection.execute(<literal sql>) to try to accomplish it. > * choose the manner of transactions, i.e. serializable, ... > what is the default transaction mode for SQLAlchemy? > in postgresql if you choose serializable your transaction > can fail and you are in charge or restarting it. you can drop into psycopg2 directly and say: connection = engine.connect() connection.connection.set_isolation_level (psycopg2.ISOLATION_LEVEL_READ_COMMITTED) session = create_session(bind_to=connection) Or you can create your own "connection" function that will automatically set this on each new connection, using a technique like the one described in the "pool" option: http://www.sqlalchemy.org/docs/dbengine.myt#dbengine_options more on pool construction: http://www.sqlalchemy.org/docs/pooling.myt#pooling_custom > > Finally, when operations are done on a session. when i do > session.flush() are > they guaranteed to be performed in order? at least when i use > transactions. > 10x. when a flush() occurs, if you havent started a transaction yourself, a transaction will be used internally to enclose all statements issued by the flush(). statements will be in order of table dependency first; i.e. sorted based on the foreign key dependencies between either tables or individual rows in the case of self-referential mappers. this means if table B contains a foreign key relationship to table A, table A's rows will always be inserted/updated first before that of table B, and table A's rows will be deleted after all changes on table B are complete. if a table A references itself, then the rows will be inserted/ updated based on the foreign key dependency of individual rows in table A. For rows within a table that dont have foreign key dependencies to each other, rows will be INSERTED based on the order the objects were added to the Session, or if they are part of a list-based collection on another object they will be inserted in the order of that collection. For UPDATES and DELETES of non-dependent rows within the same table, the ordering is generally consistent but I wouldnt say its "guaranteed" at this point since there are some Sets in use to store "dirty" and "deleted" objects in the session; I have a feeling i would need to patch the "dirty" and "deleted" Set objects in unitofwork.py to be OrderedSets and that would probably do it (although i wouldnt feel confident unless i could come up with some unittests to test that; which is tricky because Python tends to order even unordered dictionaries similarly within a single run and even across multiple runs. it might require hacking dict to return items in an explicitly randomized order to insure no dict-based ordering is in use). you should experiment with some test and example programs and have echo=True on to get a feel for the behavior of flush(). Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
