On Jun 1, 2007, at 10:53 PM, Mike Orr wrote:
> I'm not sure how your one engine registry or engine key would help
> with this. You're saying people should just get the engine through
> pylons.database.engines["default"] or something rather than going
> through the session_context?
for the general case it could be g.engine or something incredibly
obvious like that. but also, i think if people just used bound
tables (which they are anyway), you dont need to get at the engine
most of the time anyway.
>
> Alternatively, pylons.database could expose the global engine.
>
> Or one could have a SQLAlchemy class with .create_engine(),
> .make_session(), .create_session_context() methods. Then it would be
> easy to subclass that if you need to override one of the parts, and
> the other parts would automatically use your new method. Then the
> default model would have:
>
> from pylons database import SQLAlchemy
> sqla = SQLAlchemy()
> engine = sqla.create_engine()
> ctx = sqla.session_context()
>
> Does that sound like a good approach? Could it be made to scale for
> multiple engines by adding some engine key arguments?
heres a sketch:
from pylons.database import SAContext
sa = SAContext() # connects to engine in the .ini file by default
sa = SAContext(url='sqlite://', engine_args={}) # or send a url,
args in
sa.add_engine('pgconn', url='postgres://', engine_args={}) # add
engines
# create a table. metadata is a BoundMetaData to the deauflt engine.
users = Table('users', sa.metadata, Column(...)...)
# table on alt engine. metadata is a BoundMetaData to the 'pgconn'
engine.
remote_users = Table('remote_users', sa.get_metadata('pgconn'), Column
(...)...)
# mappers can bind to the sessioncontext via the SAContext directly
(its got a SessionContext inside, sends out SessionContext.ext out
via "ext")
mapper(User, users, extension=sa.ext)
mapper(RemoteUser, remote_users, extension=sa.ext)
# session. gets pulled from the SessionContext. note you never deal
with the context itself.
# session doesnt even have a bind_to, its just using the engines for
each table it gets.
sa.session.save(User())
sa.session.save(RemoteUser())
# that way this statement saves each user to its correct DB without
any issues.
sa.session.flush()
I guess whats good about the above is that its very clear what engine
youre connecting to, which is the problem i was having with pylons.
i dont totally like mixing up ORM and engine/schema but thats sort of
necessary at some point.
for other use cases, like the idea with the same tables binding to
multiple engines, either they can make their own SAContext-like
object, or maybe we can get fancy, such as:
sa = SAContext(bind_to_session=True)
which will bind engines to the Session instead of to the MetaData/
Tables, then it can have connect() and stuff like that.
At least with an object like this, we can go in and tweak it to be as
correct as possible, and the tutorials out there are just pointing at
the external interface to it so they wont be all in a semi-accurate
state as they are now (like the SA in a Hurry doc, which is currently
doing the multi-bind-engine thing).
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
