> .save() does not call .flush. flush is called only when a Query is > executed, or if you call flush() yourself. ahha. write changes just before u read again... That may mean that Querying may not be always a readonly operation as whole. Do underline this one in the docs, as it may cause greatly unexpected reactions. Of course it's not Query's problem, it's problem of the missing flush somewhere else... written by someone else...
is there a way to check if there are pending changes, so one can assert it before issueing a must-be-readonly query? > save() used to take (*args). we removed this so in order to create > a cleaner and more consistent API. (does list.append() take *args > ?) list has extend/+=. nevermind, i also have **kwargs on my saveall(-:), which i dont propose (and i regularly give it locals() - having a builtin filter on what is saveable). > > hmm. then just make .flush to issue .commit... (i know about > > different semantics etc, but most people do not want th > > Maybe even add another method meaning > > either .flush for (trans=0, autoflush=whatever) or .commit for > > (trans=1, autoflush=1), or .flush then .commit for (trans=1, > > autoflush=0). > > thats how it is right now. you're proposing that the autoflush is > the default but not the transactional part. i ain't proposing anything, just playing with combinations while trying to reduce number of methods to remember.. and which one to use in each (default) usecase. > > heh, this transactional Session() will make the antipattern 'just > > one-loooooooong-session' appear somewhat different... > > people really need to be closing out their sessions when theyre > done, *anyway*. its silly to use your session in a web > application, then leave it hanging around with all the objects in > it for the next request. Even for those people using > SessionContext, I would argue that they should create a brand new > Session at the start of each request, and remove it at the end. it > should be viewed as checking out a database connection from a > connection pool. cache. dont know about people, we use it for cache. it's probably wrong but what else can be used for cache? identity_map maybe some cache but i'm not sure about it... maybe once more topic to touch in the docs/book - in the app-to-SA view point - "how i make a cache" (vs how i use this or that SA-notion which is SA-to-app approach). btew think about these 2 approaches for the book, i think u cover mostly "how do i use this tool/API/..." which is SA-to-app, while many people would be really interested in "readymade" recipes to follow. ciao svil --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" 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/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
