[Zope-dev] Re: straighting out the SQLAlchemy integration mess

[Kapil Thangavelu]

On Wed, Apr 9, 2008 at 9:15 AM, Laurence Rowe <l at lrowe.co.uk> wrote:

> The transaction manager here:
>
>
> http://svn.plone.org/svn/collective/collective.lead/branches/elro-tpc/collective/lead/tx.py
>
> Has support for TPC and savepoints. It is tested and works. The only issue
> with sqlite is that the default in the branch is to use two-phase commit and
> sqlite does not support this. Apart from that the module is completely self
> contained.


> The public interfaces to it is the two functions at the bottom,
> join_transaction and dirty_session. The idea of the dirty_session stuff is
> to prevent unnecessary commits when data is only read. Session writes
>  trigger the 'dirtying' automatically with a SessionExtension:


>
> http://svn.plone.org/svn/collective/collective.lead/branches/elro-tpc/collective/lead/database.py
>
> The downside of this approach is that the when you interact with the
> connection directly to modify data you must call dirty_session yourself. If
> this is a problem for you then you may set up the transaction to be in the
> dirty state initially.
>
> Thread based session management is used (scoped_session). There is fairly
> extensive testing of this and the transaction support here:
>
>
> http://svn.plone.org/svn/collective/collective.lead/branches/elro-tpc/collective/lead/tests.py
>
> I think it would be worth factoring out the threaded session support as
> well as the transactions.


+1, the collective.lead transaction support looks nice.


>
>
> @Christian:
>
> I'm not quite sure what you mean by:
>
> - Database triggers as events
>
> I don't see how you could reasonably get a database trigger on the db
> server to instantiate a zope event on the db client. Perhaps the database
> could be persuaded to make a request to a URL on a trigger, but this seems a
> bit slow and maybe not a great solution.
>
> - Making SA 0.4 work with security proxies
>
> I don't know anything about security proxies in zope 3, but surely this is
> just a matter of what the base class is / the container implementation? I
> don't see why an SQL Alchemy mapped object would be any different to any
> other object.


its more to do with the fact that proxies are restrictive by default, and
the sa api likes to monkey attributes on instances. christian kicked off
some nice work with the sa developers at pycon to get this behavior
configurable in sa ( instrumentation branch) which obviate the need to
remove the proxies before calling into sa apis on an object.


>
>
> @Martin:
>
> Should one phase commit be set as the default to make it easier to work
> with sqlite (and mssql)? Probably yes.
>
> Should the default be for sessions to start out `active` or `dirty`? If
> they start out `dirty` then existing 1.0 code should work as before.
>
> It'll probably be next week before I manage to get this tidied up and
> merged back to trunk.
>
> @everyone:
>
> If we can all agree to use the same basic session and transaction
> management then we should probably push for it to be included as a
> sqlalchemy extension module.
>

sounds good, or failing that (due to additional dependencies), a common base
package.

cheers,

kapil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/zope-dev/attachments/20080409/45e1ab1a/attachment.htm