just chiming in as a company that is itching pretty hard for this
right
now, our use cases and concerns
> yeah...i think most people want to just use bind_to with their
> session in order to switch around databases for now....its the most
> expedient.
this would solve most of our problems except that we don't the ORM
bits at all and as such don't access sessions through a session
object
(i may be wrong about how this works, too, so feel free to tell me),
the options I see along this route for us is using a DynamicMetadata
and calling setEngine whenever we want to point at other places, but
living in an async world switching global stuff around feels
inherently bad.
a use case like this would work fine for us everywhere i can thnk of:
# selecting user "jimmy"
# get_engine would return the engine we want for a particular user
u = user.select().execute(nick="jimmy", engine=get_engine("jimmy"))
> the basic idea is that the Connection object would be replaced by a
> proxy which intercepts SQL and applies rules to it, which results in
> any number of activities...the two that come to mind is "execute this
> SQL on database X", the other is "execute this SQL on databases X, Y,
> and Z", where the latter is used to build instant clustered writes.
i'm in the same mind that i wouldn't actually trust non-database to
handle the clustered writes (though i see the uses for pet projects),
but what would be useful is to have a pool of engines for reads,
doesn't even need to do any load balancing just have some backups in
case a connection fails for any reason.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
