Gustavo Niemeyer wrote:
Hey Michael,
0.2 would easily alllow you to do this:
e1 = create_engine('someengine1')
e2 = create_engine('someengine2')
s1 = Session(bind_to=e1)
s2 = Session(bind_to=e2)
This is looking very interesting already!
metadata = MetaData()
mytable = Table('mytable', metadata, columns...)
m = mapper(MyClass, mytable)
obj1 = MyClass()
s1.add(obj1)
obj2 = MyClass()
s2.add(obj2)
I hate to sound like a broken record, but this is how Hibernate does it. New objects
become associated with a session by calling session.save(obj), and objects that already
exist in the database become associated with the session by calling session.update(obj).
I wouldn't be easy enough to make a custom base class that would associate the object
with the "current" session (whatever that may be). Here's a trivial example:
context = SessionContext()
class ContextualDomainObject(object):
def __init__(self, *args, **kwargs):
super(ContextualDomainObject, self).__init__(*args, **kwargs)
s = context.current_session()
s.add(self)
class MyClass(ContextualDomainObject):
pass
Of course the SessionContext is doing the magic part, but it can be implemented
any way you want really. It could even be as simple as something like this:
context.set("blue")
obj1 = MyClass() # associated with "blue" session
context.set("red")
obj2 = MyClass() # associated with "red" session
context.flush() # flushes all sessions
I think it's better to leave this type of magic up to the user rather than have
it included in the core of SA itself. It should be an explicit choice of the
developer to use magic; it should not be the default behavior of the library.
I wonder about one detail here. When obj1 and obj2 are created,
the patched __init__() method will stick them into whatever
session was active, and in that case the session.add() call
will fail due to the existent _instance_key. Doing something like
MyClass(_sa_session=s1)
would probably solve it, but that doesn't look like something
nice to have spread around the code. It'd probably be possible
to use a metaclass to stick the keyword parameter somehow.
As demonstrated above, a metaclass is not necessary. Although that would
certainly be possible.
I was thinking of something more "magical" but if you can deal with
explicit sessioning, there you go !
Actually I am thinking about something more magical, but if
SQLAlchemy has the base to support it without too much hackery,
I can probably come up with the magic myself. :-)
The problem with hacking too deeply into SQLAlchemy is that I'd
have to support these hacks forever in a fork. That's what I'm
trying to avoid.
Stuff like this shouldn't involve too much deep hacking into the SA core if it
(the core) is kept simple, and doesn't do too much of its own magic.
~ 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
