On Jul 30, 2007, at 2:55 AM, [EMAIL PROTECTED] 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. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
