i was using the antipattern of one session forever (huge non-web-app). the pros are - caching; the cons are longer: - usual cache stuff - changes to the obj in the DB won't come unless i expire it - any changes to anything keep accumulating and hence get flushed() at unexpected times. in general i guess these accumulations are more a failure on my architectural side to explicitly pronounce where changes can and where cannot happen.
this last makes it hard to chase parasitic changes/things being saved (especialy if implicitly pulled across relations); the most weird example being, for A--B via implicit many2many, creating A1, attaching some B1 to A1, then abandoning A1 (user pressed "Cancel")... still all these will be saved to DB at next flush of anything. this is like in-memory cascading is missing, or similar. the cure is to dig the session and manualy purge it from such things... not very pleasant. (there's an unfinished dbcook/usage/undo_create.py) so i guess, sooner or later, this our forever-session has to go away, but i'm not sure how exactly to disallow touching DB-objects outside the change-allowed places. i know it needs just some discipline, but is difficult to get across a team. svil On Wednesday 07 January 2009 13:08:59 Nebur wrote: > Hi folks, > SA 0.5 behaviour changes like the new auto_expire_on_commit made me > re- think about the session usage style. > I've always used to use fresh sessions for each small job to be > done. > > In fact, a session was used nearly similar to a transaction; after > any atomic operation, it is usually clear()ed or even close()d. > Only in very few places, a session was used for subsequent > operations which don't need to be atomic. Nearly as a matter of > routine, any commit() was followed by some clearing operation, > usually clear() (aka expunge_all) or even close(). > (expire_all might have been good enough in most cases - but clear() > looks like beeing on the safe side.) > > The reasons for that style of very short-living sessions were > - before each operation, I anyway have to ensure the required > objects (or the right parents) are add()ed into the session. It's > most simple to always assume the objects must be added. > - sessions that were not clear()ed often did blow tests in non- > reproduceable ways, obviously by containing stale data. > > As I said, some things have changed with current SA. By default, > each commit expires the session. Even a rollback does not > categorically damage the session (whow!) There might be reasons for > other session usage styles, e.g. let a session live longer for > performance reasons. I'd be grateful to read how other programmers > use the session objects, especially whether the session object does > live longer (or is even continued to be used after a rollback ?) > Ruben > --~--~---------~--~----~------------~-------~--~----~ 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 sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
