Ian Bicking wrote:
> 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.
Okay, I am mostly with you, but then you end up with a lot of
boilerplate elsewhere wherever you start a transaction and throw it
into the manager. I think we can address this in the TurboGears pylons
template somehow and automatically start a transaction and put it into
the manager on request by request basis, and provide some way to disable
it for read-only requests.
There have also been discussions of allowing you to turn it off for
specific HTTP methods, so you would never have a transaction for GET
unless you created it yourself, but POST, DELETE, etc. would usually
have transactions. This feels a touch too magical to me, since the
whole point of the automatic transaction-per-request in TurboGears was
to make things easy by default, and not difficult to understand.
I wouldn't have a problem if there were two separate pieces of
middleware though: one for rolling back active transactions on
exceptions, and another for setting up when you want those transactions
to be created automatically.
> 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)
>
> 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.
This database layer is acting as a middleman between the configuration
system of the framework (Pylons, etc.) and the model itself, which may
not live inside the framework. Why not just have the web framework tell
the middleman how to get the dburi from the configuration, and the model
can ask for the dburi from the middleman?
> 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.
Agreed, 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().
I'll take a look at the stuff in PEAK, but it usually breaks my brain
for at least two days before I finally grok it. But, to be fair,
StackedObjectProxy does the same thing ;)
How should we move forward with this? Is this the type of thing that
the DB-SIG cares about? Or should the discussion remain here?
--
Jonathan LaCour
http://cleverdevil.org
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
