This would be a new name available in 0.4 which would produce the same Session that we are familiar with, except it would be by default transactional and autoflushing. The create_session() function stays around and does what it always did, producing a regular session which you flush().
Its currently implemented in the trunk, and we think we will probably release 0.4 as a beta since we really need to get you guys playing with it, but not in that "i just put it on production and it broke" kind of way. The transactional/autoflushing session would work like this: >>> sess = Session() >>> u = User(name='john') >>> sess.save(u) >>> # user is available immediately, as its flushed by >>> # the time we query >>> sess.query(User).filter_by(name='john').one() <User(name='john')> >>> # persist data to the database permanently >>> sess.commit() flush() is still there and does what it always did, should you want to call it explicitly. I also would be resurrecting a very old function that's just been hidden all this time, which I think might be nice, which is rollback(): >>> # change john's name >>> user.name = 'ed' >>> # rollback changes. rolls back the transaction *and* in memory changes >>> sess.rollback() >>> user.name # user's name back to 'john'. works for collections too. 'john' >>> # close the session >>> sess.close() One caveat of the above is that, particularly with Postgres, you *really* need to commit or close the session when you're done, to release connection resources..postgres locks aggressively. Advantages to this new approach: - queries return everything you've just done in the session automatically without any need to call flush(); theres no more disconnect between the objects you save() and update() in the session and your queries. - this is how Hibernate has always worked, so its a pretty proven model (except for the rollback part) - in particular, a new kind of relation we have called a "dynamic" relation makes good use of this; its basically a Query tacked on to a special collection which receives only append() and remove() events. all iteration and array operations from this relation query the database immediately. - transactional behavior means the Session uses a single connection, then holds onto it for a large set of operations. this improves consistency and puts less stress on the connection pool. - the transaction also allows autoflush and rollback() to make more sense....no need to worry that things were flushed too soon. Disadvantages: "magical" - now, you might have FlushErrors being raised when all you wanted to do was issue a Query. this might be confusing. - issues more SQL - if you are manipulating objects and querying as well, by the time you get to commit() you may have flushed many times, whereas previously you would only have flushed once at the end. - transactional - you really need to close() and/or commit() the session, if its going to continue hanging around; it references connection/transactional resources. Postgres in particular really likes to hang up if tables are still locked (although i notice this mostly with our unit tests which have to DROP tables a lot). - transactional again - a lot of you use MySQL with ISAM tables, these are not transactional. might get inconsistent results. while we have both Session() and create_session() in the trunk now, Session() would be what we document going forward. flags to make it act other ways are still available, like autoflush/transactional. any thoughts ? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
