yes. but i'll always have to use a bind anyway. this routing style has a
problem to identify what entity you're querying (and then the mapper)
when using functions, either at column level
"session.query(func.count(MyObj.attribute))" or at the query level
itself "session.query(MyObj.attribute).count()", among other functions
(exists, etc).
best regards,
richard.
On 05/18/2014 05:04 PM, Michael Bayer wrote:
well if you're working with the RoutingSession example you can
manufacture get_bind() and using_bind() to work in any way you want.
If you have the engine, as the example shows,
session.using_bind(some_bind).query(...)
http://techspot.zzzeek.org/2012/01/11/django-style-database-routers-in-sqlalchemy/
On May 18, 2014, at 3:28 PM, Richard Gerd Kuesters
<rich...@humantech.com.br> wrote:
yeah, well, i was using implicit for little things and explicit for
the bigger ones, but it seems that even small things are error prone
:) i was just wondering if there's a "faster" way to do it, even
explicit, so i can get a class (whatever it is) to query against an
engine i know (so there's the key to make things work). if I have a
metadata bind to some engine, is there a quick (and performatic) way
to know it?
Em 2014-05-18 16:21, Michael Bayer escreveu:
On May 18, 2014, at 12:10 PM, Richard Gerd Kuesters
<rich...@humantech.com.br <mailto:rich...@humantech.com.br>> wrote:
well, this part is still working, as long as i remember. my biggest
problem now - and has been for the last couple of years - is to
manage this mayhem of classes and engines AND sessions, because
everyone "wants to go online" with their data. i'm writting and
rewriting a session manager that can simplify my life for a
looooong time, i got close to get things done with your
RoutingSession vertical example, but it doesn't work very well with
functions, session.query(...).count() or .exists() and so on. i'm
writing code as hell and still far from an acceptable, performatic
session "router" (?) for a class that can come from anywhere, for
one or more specific engines, without grind string ids everywhere.
well, i think my problem have a lot of weaknesses to discuss ...
but, one at a time.
for now, any tips on enterprise multi-everything session routing? :)
you're trying to route to different sessions based on the
intricacies of what's inside a SELECT statement? See I just would
never do that, it's very complicated and error prone. I'd have an
explicit node name sent in right at the top. Explicit is better
than implicit.
--
You received this message because you are subscribed to the Google
Groups "sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to sqlalchemy+unsubscr...@googlegroups.com
<mailto:sqlalchemy+unsubscr...@googlegroups.com>.
To post to this group, send email to sqlalchemy@googlegroups.com
<mailto:sqlalchemy@googlegroups.com>.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to sqlalchemy+unsubscr...@googlegroups.com
<mailto:sqlalchemy+unsubscr...@googlegroups.com>.
To post to this group, send email to sqlalchemy@googlegroups.com
<mailto:sqlalchemy@googlegroups.com>.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
