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
