TurboGears-1.5 and transactions

[dbrattli]

Hi,

With TG-1.5 we can now run database transactions as a CP3 tool instead
of @expose. That way you can easily decide which controllers that gets
transactions and who don't by only enabling/disabling the CP3 tool for
specific controllers. I think it would be nice to get transaction
handling away from expose/entangle. So I've written a CP3 tool to
handle transactions. Thus to enable transactions you simply have to
add the Transaction tool to some startup code (commands.py or
startup.py etc):

cherrypy.tools.transactions = TransactionTool()

The tool could be enabled with either:

tools.transactions.on = True

or enabling it in the RootController:

_cp_config = {
'tools.transactions.on' : True,
}

That way it's easy to have fine level control of each exposed
controller and enable/disable transactions where needed. I would like
to contribute this idea to TG-1.5 and think it would be great if we
could get this into place. I've only tried this with SO so the tool
probably need some more code to handle SA as well, but it shouldn't
difficult . Please give me comments and suggestions on how to improve
it and if it's interesting to remove the transactions handling away
from @expose. (I think @expose does to much already). But maybe
there's some side-effects I've forgot about?. Here's the tool:

import cherrypy
from turbogears.database import commit_all, end_all, rollback_all

class TransactionTool(cherrypy.Tool):
"""A TurboGears 1.5 Transaction tool"""
def __init__(self):
return super(TransactionTool,
self).__init__("on_start_resource", self.begin)

def begin(self):
# To make sure TG does not run with transactions
cherrypy.request.in_transaction = True

def _setup(self):
conf = self._merged_args()
p = conf.pop("priority", None)
if p is None:
p = getattr(self.callable, "priority", self._priority)

cherrypy.request.hooks.attach(self._point, self.callable,
priority=p, **conf)

cherrypy.request.hooks.attach('before_error_response',
rollback_all)

# Lower priority for commit to run before TG EndTransactions
hook
cherrypy.request.hooks.attach('on_end_resource', commit_all,
priority=40)

# Not necessary because of TG EndTransactions hook, but
perhaps we could
# remove the hook and use this tool instead?
cherrypy.request.hooks.attach('on_end_request', end_all,
priority=50)

[Florent Aide]

On 8/22/08, dbrattli <dbra...@gmail.com> wrote:
>
> Hi,
>
> With TG-1.5 we can now run database transactions as a CP3 tool instead
> of @expose. That way you can easily decide which controllers that gets
> transactions and who don't by only enabling/disabling the CP3 tool for
> specific controllers. I think it would be nice to get transaction
> handling away from expose/entangle. So I've written a CP3 tool to
> handle transactions.

The idea seems interesting. We should think about the implications.
Factoring the transactions handling out of the tg core is one of the
improvements of tg2.

But to get this refactoring moving we would need to have an easy to
install tg1transaction manager. I am wondering if we could not use
remoze.tm in tg 1.5 since CP3 is wsgi compliant... This would make us
even more close to tg2.

I'll need to think about this after tonight releases :)

Florent.

[Mark Ramm]

> But to get this refactoring moving we would need to have an easy to
> install tg1transaction manager. I am wondering if we could not use
> remoze.tm in tg 1.5 since CP3 is wsgi compliant... This would make us
> even more close to tg2.

An alternative would be to make repoze.tm into a cp3 tool. This in
some ways would be the best of all worlds, because it would allow for
1.5 code to use the same API as tg2 for managing transactions in
controllers ( eg, killing a transaction with transaction.doom() ) and
would take advantage of the the performance and flexibility that CP3
tools provide.

[iain duncan]

+1 on that idea from a users perspective. Seems the most like putting
the right tool in the right place.

Iain

[Florent Aide]

On 8/22/08, iain duncan <iaind...@telus.net> wrote:

> > > install tg1transaction manager. I am wondering if we could not use
> > > remoze.tm in tg 1.5 since CP3 is wsgi compliant... This would make us
> > > even more close to tg2.
> >

> +1 on that idea from a users perspective. Seems the most like putting
> the right tool in the right place.

Ok, we all agree that using repoze.tm with CP3 would be the best :)
Who volunteers to do the job then ?

Florent.

[Alberto Valverde]

On Aug 24, 2008, at 5:07 PM, "Florent Aide" <floren...@gmail.com>
wrote:

I think that what Mark tried to say was that we should use
'transaction' but reimplement repoze.tm2 as a CP tool for performance.
I'm +1 on any solution that uses transaction + zope.sqlalchemy since
it's what tg2 is using already.

Alberto

[dbrattli]

Hi, i had an accident in a bike race yesterday, and cannot help out
for some days/weeks. But tools are good since they don't affect the
whole app as wsgi!?

-- Dag

On Aug 24, 5:07 pm, "Florent Aide" <florent.a...@gmail.com> wrote:

[mark.mch...@gmail.com]

On Aug 24, 3:41 pm, dbrattli <dbrat...@gmail.com> wrote:
> Hi, i had an accident in a bike race yesterday, and cannot help out
> for some days/weeks. But tools are good since they don't affect the
> whole app as wsgi!?

exactly, tools can apply to only some parts of the tree.

[indigophone]

I had a discussion with Mark on freenode about problems related to
this. When using SQLAlchemy 0.5, committing in expose function breaks.
It is causing a new session to be created and then the model cannot be
accessed within the template. Mark told me he believes it is related
to internal redirects causing a commit and then the session is closed.

Please let me know what other information you need from me regarding
this.