Jonathan LaCour 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.
The way I see this working is something like (vaguely):
def transaction_middleware(app):
def wrapper(environ, start_response):
manager = TransactionManager()
environ['transaction.manager'] = manager
try:
app_iter = app(environ, start_response)
except:
manager.rollback()
raise
else:
manager.commit()
The manager is basically a container of *actual* transactions, and
calling rollback or commit on it gets passed on to all the transactions
in the manager.
If you don't do anything that needs a transaction (e.g., read-only), you
shouldn't put your transaction in the manager.
> 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)
>
> So, I am a big +1 on such a beast.
I'd kind of like a way of getting the "current" WSGI environment. Then
one possible implementation of this config-getter is:
def get_dburi():
environ = get_environ()
return environ['paste.config']['dburi']
Or it could get it out of another key, of course. And in a non-web
context you have a different get_dburi() implementation. The only
annoying part is actually figuring out how you get that function, and
how you provide that function.
The way they do it in Zope, which is similar in ways to Paste's
StackedObjectProxy and paste.registry, is basically something like:
dburi = getUtility('get_dburi')()
Except in Zope they use an interface instead of 'get_dburi'. But I
think we should use a string.
We might want to look at PEAK's contextual stuff, as this is basically
addressing the same problem. I believe Phillip recently extracted that
from PEAK. (And all this config stuff is exactly the same issue as
getting the current transaction manager.) Personally I'm not terribly
comfortable with paste.registry and StackedObjectProxy, as I feel it
pretends to be more transparent than it really is; I prefer something
more explicit like getUtility().
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
| Write code, do good | http://topp.openplans.org/careers
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
