On 6/1/07, Michael Bayer <[EMAIL PROTECTED]> wrote: > Mike Orr wrote: > > Could we have session.engine be an alias for session.bind_to? Pretty > > please? The only reason I leave a top-level 'engine' around is in > > case I need it for something, because .bind_to is so non-obvious. > > pylons is the reason pulling the engine off the session is even > becoming popular, because it is actually using the bind_to feature, > as well as that it didnt really create any easy way to get at the > engine repository (not to mention the issues i raised on the pylons > list). things to note about bind_to is that the session may not be > bound to anything, and also can be bound to *multiple* engines in the > case that someone is making it do that. which is why the "official" > way to get the engine is session.get_bind(<mapper>). i dont know > what im saying here other than im getting a little antsy about > session / engine /etc being muddied / TMTOWTDI. theres too many > choices but in this case people wanted them.
I assume you're referring to this thread: http://groups.google.com/group/pylons-discuss/browse_thread/thread/747ac14d1e20f332/a650fb1011ec2387?lnk=gst&q=michael+bayer+sqlalchemy&rnum=1 Subject: Pylons Integration of SQLAlchemy config extremely broken Date: 2007-05-25 A couple older threads which are slightly obsolete: http://groups.google.com/group/pylons-discuss/browse_thread/thread/70fecb3d8da1aec8/a78e2fb66d8e4baa?lnk=gst&q=michael+bayer+sqlalchemy&rnum=5 Subject: SQLAlchemy best practices Date: 2006-09-20 http://groups.google.com/group/pylons-discuss/browse_thread/thread/1f05fee97b1e5217/f424e9f51f7e3627?lnk=gst&q=michael+bayer+sqlalchemy&rnum=6#f424e9f51f7e3627 Subject: ANN: Pylons 0.9.4 released Date: 2006-12-30 There is agreement in the Pylons group that pylons.database needs to be improved. Both you and I and others need to pass in more create_engine options. I'm contemplating a patch that would read all currently-defined options from the config file, converting those known to be ints or bool, and skipping those requiring non-scalar values. That would solve a large chunk of people's problems. Multiple engines make my head spin. Why do you need that unless you're connecting to two different databases in the same application? And even if you did, wouldn't you define a second top-level session_context to bind it to, with its own different metadata and tables, and never the twain shall mix? I don't want a registry of engines or something in the 'g' object. What I want is a simple out-of-the box configuration for simple sites, but more robust than what Pylons currently has. Maybe we'll have to come up with separate simple and advanced configurations if others need multiple engines and whatnot. I also don't like how pylons.database initializes a session_context at import time rather than providing a create_session_context function, so that's another thing to add to my patch. Otherwise if you can't use pylons.database.create_engine() for some reason, you have to duplicate a lot of code to recreate or bypass the default session_context, and this includes writing stub functions because SessionContext takes a session factory function with takes a create_engine function, so there's no way to customize the create_engine from the SessionContext constructor directly. Methinks SQLAlchemy is contributing to the problem with its long hierarchy of engine -> metadata -> session -> session_context, but I don't have the expertise to say what might be better. But certainly it's annoying that: - SessionContext doesn't take both create_engine and make_session arguments, or arguments to pass through to those, and build your ideal engine -> session -> session_context hierarchy on the fly. Instead you have to create a dummy make_session function just to tell it which create_engine to use. This is part of why overriding Pylons' default session_context requires reimplementing three whole functions. - This is a part of the previous, but SessionContext in the manual says, "A common customization is a Session which needs to explicitly bind to a particular Engine." Yes, so why doesn't SQLAlchemy provide a way to handle this common case without the user having to define his own make_session? Again, SessionContext -- or a create_session_context function -- could do this for you if you pass an 'engine' argument. - Metadata seems like an implementation detail. I have to define a metadata just to pass it to my Table's, then I never use it again. There is global_connect() which hides it, but its use seems discouraged. Plus global_connect gets into all that DynamicMetaData complication, such as whether it will autoconnect properly in the other threads. Perhaps what I'm asking for is a global_bound_connect or something? I can see why the metadata can't be subsumed into the engine because you may want to connect the same metadata back and forth if you're copying data from one database to another. And I can see why it can't be subsumed into create_session_context because you need it before that to autoload the tables. So it's kind of the centerpiece that holds those two together and also holds the tables. So maybe making the metadata less obtrusive is insolvable. I don't know whether the answer is to collapse the hierarchy so it's not function-calling-function-calling-function or what. Probably that would be too disruptive to existing users and make SQLAlchemy less flexible/useful. But I just wonder how much of this hierarchy is really necessary/useful, and how much should just be subsumed in an uber one-session-context-to-rule-them-all like pylons.database does. I'm only doing ctx.current.bind_to because Pylons makes that easy, and because as a naive user I wouldn't know whether it's safe to stray away from that recommendation. Users know not to share a session between threads, that they should use session_context even though they don't quite understand what it does, but they can get confused whether an engine or metadata or anything else that's accessed through a session_context is compatible with one declared or used at top level in another thread. I would be in favor of a more straightforward approach in my model: engine = create_engine(...) meta = BoundMetaData(engine) ctx = create_session_context(engine, meta, session_options) But under the current SQLAlchemy this would require more lines of code than just that. Would this be "better" than just using the session_context Pylons provides for me and doing ctx.current.bind_to? I'm not sure. -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
