hey Dan -
just FYI, the current 0.2 Session implementation regarding this is
looking like the following (hibernate's "save" is "add", hibernate's
"update" is "import_". both of which at the moment seem to be
clearer names to me, but maybe you see it differently...possibly not
consistent with "delete", yah ok....):
def add(self, entity_name=None, *obj):
"""adds unsaved objects to this Session.
If an entity_name is given, then the objects are also assigned
that entity_name by the mapper corresponding to that class/
entity_name combination.
"""
def import_(self, instance, entity_name=None):
"""given an instance that represents a saved item, adds it
to this session.
the return value is either the given instance, or if an
instance corresponding to the
identity of the given instance already exists within this
session, then that instance is returned;
the returned instance should always be used following this
method.
if the given instance does not have an _instance_key and
also does not have all
of its primary key attributes populated, an exception is
raised. similarly, if no
mapper can be located for the given instance, an exception
is raised.
this method should be used for any object instance that is
coming from a serialized
storage, or was loaded by a Session other than this one.
the parameter entity_name is optional and is used to locate
a Mapper for this
class which also specifies the given entity name.
"""
def delete(self, entity_name=None, *obj):
"""registers the given objects to be deleted upon the next
flush(). If the given objects are not part of this
Session, they will be imported. the objects are expected to
either have an _instance_key
attribute or have all of their primary key attributes
populated."""
On Apr 19, 2006, at 7:08 PM, Daniel Miller wrote:
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
-------------------------------------------------------
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
