[sqlalchemy] Re: PROPOSAL: Session
On Sunday 29 July 2007 23:36:32 Michael Bayer wrote: 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(). 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 ? 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... will the readonly= flag go in too? 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) And, would this mean that in an autoflushing session calling .flush is useless (being called anyway after each .save automaticaly)? 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). heh, this transactional Session() will make the antipattern 'just one-lng-session' appear somewhat different... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: PROPOSAL: Session
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-lng-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 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: PROPOSAL: Session
On Jul 30, 2007, at 2:14 PM, [EMAIL PROTECTED] wrote: 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... then you turn off autoflush and transactional. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Proposal: session identity_map no longer weak referencing
when SA was first released, someone immediately suggested that the identity map of Session be weak referencing, which appeared to be an obvious improvement, so that you could load as many objects as you want from the session and whatever you didnt use would just go away. but now it appears that the more intuitive operation for a Session is that things that get loaded into it, stay there, until you say otherwise. If I got what yoy mean, I think I had suggested something like that myself... but it was back in SA 0.1 days, when there was no explicit Session. But are you saying that doing sth like a = MappedObject() session.save(a) del a would prevent 'a' from being saved when flushing the session? In SA 0.3.1 it seems to stay in it. Or it's just a matter of changed attributes, something like a = query.get_by(id=x) a.attribute = 4 del a ? In both cases, I think the strongly referenced behaviour is OK. If it's in a session, I want an object to be tracked whatsoever, unless I explicitly remove it. -- Alan Franzoni [EMAIL PROTECTED] - Togli .xyz dalla mia email per contattarmi. Remove .xyz from my address in order to contact me. - GPG Key Fingerprint (Key ID = FE068F3E): 5C77 9DC3 BD5B 3A28 E7BC 921A 0255 42AA FE06 8F3E --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Proposal: session identity_map no longer weak referencing
On 12/8/06, Michael Bayer [EMAIL PROTECTED] wrote: when SA was first released, someone immediately suggested that the identity map of Session be weak referencing, which appeared to be an obvious improvement, so that you could load as many objects as you want from the session and whatever you didnt use would just go away. but now it appears that the more intuitive operation for a Session is that things that get loaded into it, stay there, until you say otherwise. So id like to make the session act this way, again like hibernate's...more explicit. what you load into the session stays there until you clean it out. that behavior is more predictable than what we have now. +1 Of course we can always add an option weak_identity_map if people really do want the old behavior. -1, it's only a matter of time before this would bite you -- Jonathan Ellis http://spyced.blogspot.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
