On Apr 27, 2006, at 11:05 PM, Daniel Miller wrote:
I assume you're implicitly referring to any method that would call
Session._bind_to(). Personally, I think Session._bind_to() should
raise an exception if the object-to-be-bound is associated with
some other _open_ session (rather than silently removing it from
the other session). If one really wants to move an object from one
session to another it should be two steps like this:
old_session.expunge(obj)
new_session.update(obj)
that will be fine for starters, i.e. raising the exception, although
theres a chance it might not work out. I dont think people are going
to use update() very much anyway unless they have two sessions being
dealt with explicitly. the one case i was concerned about is the
example of "store this object in the HTTP session, then on the next
request bring it back into the current unit of work", and i dont want
to force everyone to do a session.close() in a simple web application
(unlike hibernate, an open Session doesnt leave any connectional
resources open unless theres a transaction started). but that
operation would be done via merge() which actually does not affect
the given instance.
the __session__() method is only called to get a session, *when
the instance is not already associated with a session*. this
method is merely there as the standard way to plug into systems
such as the SessionContext __metaclass__ youve built, which is
associating classes with a particular session context.
Actually, it's not doing that at all. It's associating instances
with a particular Session (not a SessionContext). OK, the base/meta
classes do (internally) associate the object with a context. But
there should be no need to obtain the context from an instance.
When the current session is needed it should be obtained directly
from the context and not through some arbitrary mapped-object
instance. If a user needs to pass a context around, then he should
do that with his own plumbing.
It seems that you are saying you never want an instance added to a
Session automatically, in any case, ever - SA in all cases requires
an explicit save()/save-or-update(), and there is no way to change
that behavior, since there is no internal mechanism for a mapper to
get a session for an instance just created (recall that Mapper
decorates a classes' __init__ method to make this possible). correct ?
if that is the case, then we disagree; I believe there must be an
"implicit session" pattern available, never by default but very easy
to turn on without any extra programming, and should also be
customizable. This pattern seems to be very well accepted by the
current SA userbase and i dont think it should be removed:
mapper(User, user_table)
u = User() # 'u' is now associated with a session
The above could be using just the thread-local session, but i thought
it was a nice idea that you could also associate the User class with
a particular session context. otherwise i dont really understand the
point of having the baseclass and metaclass you proposed, it seems
kind of cruel to supply an extension that associates sessions with
objects, but then SA has no way to use it automatically.
[__session__() is] also not the kind of function people would
implement on a casual basis, its there to make a more advanced
concept possible in a clean, non-monkeypatching way.
perhaps naming __session__() as __sessioncontext__(), and having
it return a callable which then returns the contextual Session,
will make it clearer...though that seems more confusing.
From an OO perspective, allowing the contextual-session to be
obtained from an instance essentially gives that instance two
sessions--the one it is bound to and the context-current one. I
think that's a "Bozo-No-No" as my old CompSci prof used to say.
Just because you can doesn't mean you should... Really, I see no
need for this. If the (SA) framework really needs to know about the
contextual session, then provide a way to explicitly get a
SessionContext instance rather than using magic methods.
we can play rock-em-sock-em straw men if you want: I doubt your comp
sci class was teaching Python...what do you think he would say if you
told him "the effective type of an object should be determinable
based solely on the methods that happen to be available off of
it" ? im sure he would have flunked Guido.
back to the issue at hand, the distinguishment to be made with the
__sessioncontext__ method, and i should make this clearer, is that we
are associating a session context with a class, not an instance.
so there is no "two sessions with an instance" going on, the instance
has one session, the class is optionally associated with a particular
context. the instance may contain a state that is specialized
against the default supplied by the class, and there is nothing wrong
with that. just like you associate a Mapper with the class, but an
instance might have been loaded by a different Mapper. it could be
done the opposite way, you can stick your SessionContext callable
into the mapper() call; same deal. Maybe that is a little
clearer. although then you cant easily associate a full class
hierarchy with a particular context...
At any rate, I would wait to implement it until someone asks for
it... There that's all I'll say about that.
yah i dont need to implement this right now but i dont see the point
of including the SessionContext package in SA if its not integratable
with SA. If it is only useable as part of a larger "use it to write
your own framework!", then we cant really write a complete document
for it; it would have to be "heres a code fragment, but this part in
the middle, you have to write yourself". That may fly in Java, but
trust me, if you do that in Python, nobody will bother. The folks
that have the will to write their own framework would just stick
their own threadlocal variable on their class, and the folks that
dont are simply not going to bother.
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
