[sqlalchemy] Re: PROPOSAL: Session - Michael Bayer - com.googlegroups.sqlalchemy

6 messages in com.googlegroups.sqlalchemy[sqlalchemy] Re: PROPOSAL: Session

From	Sent On	Attachments
Michael Bayer	29 Jul 2007 13:36
Michael Bayer	29 Jul 2007 20:17
sdob...@sistechnology.com	29 Jul 2007 23:55
Michael Bayer	30 Jul 2007 07:18
sdob...@sistechnology.com	30 Jul 2007 11:13
Michael Bayer	30 Jul 2007 13:24

Subject:	[sqlalchemy] Re: PROPOSAL: Session
From:	Michael Bayer (mike...@zzzcomputing.com)
Date:	07/30/2007 07:18:27 AM
List:	com.googlegroups.sqlalchemy

On Jul 30, 2007, at 2:55 AM, sdob...@sistechnology.com wrote:

as long as u have both ways (autoflush/noauto, trans/notrans) on same object - flags etc - and the difference is well documented, and the usage patterns of both (or are there 4 combinations) are explained...

of course the flags will be documented; but for that number of users who dont like to bother with flags, or are going to write their apps such that they say Session(foo=bar, x=y) in hundreds of places instead of creating a function, what we're really looking for here is "what should the default behavior be"? the disadvantage SA has here, as in many other areas, is that we even *have* a choice in the first place.

will the readonly= flag go in too?

possibly; im not as psyched about this flag and maybe it will be a 0.4xx thing.

btw is autoflushing meaning that .save always calls .flush, instance-per-instance? Then how about making sess.save working over list or *args and saving them all? (may be another method savemany that just calls save in a loop)

.save() does not call .flush. flush is called only when a Query is executed, or if you call flush() yourself.

save() used to take (*args). we removed this so in order to create a cleaner and more consistent API. (does list.append() take *args ?)

And, would this mean that in an autoflushing session calling .flush is useless (being called anyway after each .save automaticaly)?

a "useless" flush looks in the current list of objects, finds nothing, and then doesnt do anything.

hmm. then just make .flush to issue .commit... (i know about different semantics etc, but most people do not want the semantix, they just want the data going to db). 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.

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.