Michael Bayer wrote:
my current proposal regarding the association of objects to sessions, as
well as the optional association of objects and classes to "session
contexts", is as follows: ...
Great! this looks pretty good.
I do have a few comments on your other email though. Here goes...
Michael Bayer wrote (in an off-list email):
just to be clear, we arent changing the fact that a particular instance
can only be assocated with a single Session at a time, and also we arent
changing the fact that once an object is associated with a particular
Session, that Session is where it remains associated
No, I do not want to change either of those things. In fact, I'm trying to make
sure people know when they do things that would seem to violate them.
until some explicit
step to attach it to some other session is performed.
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)
For most people it will not matter since it's not very common to transfer
objects between sessions like that. The explicit removal before re-association
provides a warning for people who inadvertently try to update an object with
the wrong session. The most common semantics of Session.update(obj) relate to
transient instances, and it should cause an error if the object being updated
is not transient. Not to mention, it requires less code... :)
If you really think it's necessary to have this functionality in a single call,
I would recommend it be done with a flag, but this is definitely my second
choice:
new_session.update(obj, force=True)
One more note: new_session.update(obj) should not raise an exception if the
old_session has been closed.
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.
[__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.
At any rate, I would wait to implement it until someone asks for it... There
that's all I'll say about that.
but since we are going with the hibernate model of objects coming in and
out of sessions freely, I agree that get_session() should return only
the contextual session (or None), and some other function returns the
session to which an object is already bound (or None) would be used
throughout the mapper. the same thing here where get_session() would be
clearer as "get_current_context(obj).get_session()" applies, but that
seems a little unpythonically verbose to me. i suppose the functions
should be named differently, such as "current_session(obj)" and
"object_session(obj)", something like that.
Right, that's all I really care about. As long as those two functions are
separate we're good.
In fact, I don't even think Hibernate provides a way to get the
session from an object.
What does SessionContext do then ?
It's something used at the framework level to provide a way of obtaining the
current session. It looks like it's normally owned by a SessionFactory
instance. It does not provide a way to get the session of a particular object,
rather it provides a way to get the current session in some scope, which is
defined by the implementation of CurrentSessionContext.
~ Daniel
-------------------------------------------------------
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
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
