On 6/27/07, Jonathan LaCour <[EMAIL PROTECTED]> wrote: > > Ian Bicking wrote: > > > Personally I'd like to see something a bit different: > > > > * Way for a library to get "the" transaction manager. > > * Interface for that transaction manager, maybe copied from Zope. > > * Single convention for how to specify a database connection (ideally > > string-based). > > * Probably a way to get "the" configuration, so you can lazily get > > a connection based on the configured connection. > > > > The frameworks would setup the transaction manager and configuration, > > and database frameworks would basically consume this information. > > This would be pretty much ideal, and would satisfy my use cases very > well. It would also allow framework authors to build in support for any > ORM / database layer in an agnostic way, sort of like the Buffet API > does for templating systems. > > Then, we could also create a simple WSGI middleware for Pylons that > gives it TurboGears-like automatic transaction start/commit/rollback > on a per request basis. Only, we could make it configurable so that > it didn't happen on read-only operations. All of this would be ORM / > database layer agnostic, which would be very nice indeed.
All this is to avoid a try-commit block in the controller method or model function? Is it really that important? Is this what Noah means by "controlling transactions"? The normal Pylons strategy is to clear the SQLAlchemy session in the base controller before calling the action method. This is effectively a rollback, but since all the changes are in memory and haven't been compiled to SQL yet, no rollback is necessary. Users do sac.session.flush() to write their changes to the database, which is essentially a commit. I'm more comfortable with that happening explicitly in the controller method rather than vaguely in some middleware (especially since the application is not supposed to know or care whether a certain middleware is active). As for direct SQL statements in SQLAlchemy, I just assume they're autocommit. Maybe someday I'll have to get more sophistocated about them. > The big issue for me with SAContext right now is that it uses a > BoundMetaData and expects you to know your dburi "up-front" as it > were. I don't like having my model tied to my configuration system. > I'd rather have my model fetch its configuration from some third party > source, such as this new package we are discussing, so that I can > create desktop applications, command line utilities, etc. that share my > pylons application's model, without having to ship pylons or a pylons > configuration file. The last thing that Ian requests here would let me > do that to a certain extent: > > from db_buffet_api import config > from sacontext import SAContext > > sac = SAContext(dburi=config.dburi) If that's all you want, it already does this. SAContext requires an explicit URI and options as arguments, and doesn't know about anybody's configuration system. My hope is that it will be included in SQLAlchemy at some point, for many diverse applications. PylonsSAContext addresses the needs Pylons users have right now: a standard way to configure an engine/metadata/session that's better than pylons.database. The overriding concerns are: - Correctness per SQLAlchemy's recommendation (which favors BoundMetaData, even though the SQLAlchemy manual hasn't gone that far yet). - Easy for users to put into their model (just a couple short lines of code). - Automatically reads all engine options from the config file that can be specified in a scalar format. - Accepts other engine options from the developer which can't be expressed in a scalar format. If your concept requires something different than PylonsSAContext, perhaps a different subclass, there's no reason the two can't live side by side. The model is "tied" to the configuration such that you can't import it standalone, at least if you follow the SAC_Demo example. Instead you have to use the module under "paster shell", "paster setup-app", or manually prepare the environment for the import (which is not well documented but websetup.py gives some hints). This is *no worse* than existing Pylons usage, which also has the same limitation. We have thought long about how to improve this but have not come up with a better way. Some people put all their tables in an init function in the model so that it can be called sometime after the actual import, and with arguments. This is a little better in some ways but still not a robust solution. Do you set global variables for the tables or pass them back as the return value? Either way is messy. Of course the engine must be initialized before any tables can be defined or any work done. SAContext initializes the default engine in the constructor. Is there a need to push that back to some later stage? Which stage? Or can Ian's ideal wrapper simply delay creating the 'sac' until it has to? -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
