hey dan -
to give you an idea, check out http://www.sqlalchemy.org/trac/
changeset/1262
if you check that one out i think your lazyloader issue should be
resolved (added a unit test for that).
the next phase would be the using() method gives you a proxying
object that just adds the "session" keyword argument as appropriate.
and then maybe doing something similar with an "engine" keyword
argument. then maybe some cleanup of mapper method signatures and
we're just about there with sessions/engines totally per-call. As
"engine" is already a keyword argument to most of the SQL
construction objects, and Ive removed the "type" dependency
yesterday, I think itll be quite easy to create and use Table objects
with an engine of "None" in the very near future.
fortunately, its all Python....none of this is very hard....
On Apr 6, 2006, at 2:53 PM, dmiller wrote:
On Apr 6, 2006, at 2:23 PM, Michael Bayer wrote:
dan -
just to make sure, we arent calling for a rewrite to the whole API
for SQLAlchemy.
Not at all. Granted, the Query interface that I was talking about
would be exactly like the current mapper API but it wouldn't live
in the mapper, but it's just one proposal, I'm not sold on it. If
you've got a way to make my suggestions work with the current API
I'm very interested in that too. BTW, the more I think about it the
more I don't like the name 'Query' either...
While the internals of the using() function are hacking around the
global session registry, i am as interested as you are in making
it more inline, since at the very least it would operate more
efficiently. I am definitely interested in improving SA's support
for explicit sessions throughout, and making the Session registry
a totally optional thing, if one wants to specify explicit
Sessions everywhere. the code is very close to being able to do
this anyway, there are only a few places in Mapper where it uses
get_session() which can be wrapped with some extra contextual
logic, which will be similar to the Query idea youre getting at,
and also fixes the lazyloader thing youre having...im adding a few
more "session" arguments to some mapper methods right now that
should get at least that part working.
Good! If the session is passed inline, does that mean we'll be
making mapper.select, mapper.select_by, etc. methods do a "using
(objectstore.get_session())" internally? That's basically what I
was suggesting except you're moving the internals of the mapper
into the thing returned by "using()" rather than moving the query
statements out to a new object (probably the right thing to do for
backward compatibility). The only (small) problem with that is the
default implementation of mapper depends on the thread-local
pattern (i.e. I could never use mapper.select(...) if I didn't want
thread-local).
but if I may defend the concept of a registry, its a very well
accepted pattern, and thread-bound transactions are used by
Hibernate /JTA to eliminate the need for transactional objects to
be passed to all method calls everywhere. I dont really think the
"they taught you in school that global variables are bad" argument
is very pertinent here. heres fowlers description of it:
http://www.martinfowler.com/eaaCatalog/registry.html .
I don't have a problem with the concept of a global registry
itself. I think it's a good pattern, and I have even used it
myself. I do have a problem with the fact that mapper depends on
the global session registry, which we both agree needs to change.
of course a global registry is entirely inapprorpriate for your
application, and restructuring SA to not be dependent on it is
something we agree on (even though I could make it all work along
the lines of the using() idea, its simply wasteful of processing
time to have to push/pop onto a stack for every method call).
I am aware of this as well. I was thinking about mentioning the
inefficiency argument too, but I was afraid you might tell me to
just suck it up...
Thanks for all your hard work.
~ Daniel
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the
live webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?
cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
