[Twisted-Python] SQLAlchemy integration

[Ed Suominen]

>>> I'm writing some modules for integrating SQLALchemy with Twisted.
>>> The idea is to write a custom Pool, EngineStrategy and Engine for Twisted.
>>> I would like to know if there are some other people working on this
>>> (excluding sAsync)
>> Is there really a good reason for having *two* different efforts to
>> integrate Twisted with a single other library?  Surely it must be
>> possible to collaborate somehow.

I agree with Glyph. I've put a ton of effort into sAsync, which would
cost thousands of dollars at even a fraction of what I charge for "real"
work. Why not make use of that?

It is GPL'd, but I have one user implementing it in a commercial project
now under a special license that he obtained by doing some coding of his
own for me. (My thanks to the Twisted developers for making Twisted
itself available under a no-strings-attached license, and thus providing
me the opportunity for that sort of modest compensation.)

> This works because Engine implements the Connectable interface.
> There is an issue here: if a query/table is bound to this Engine, every
> query will run in a separate thread; this is not what one want when
> inside a transaction).

Perhaps you should take a closer look at what sAsync does before
dismissing it. sAsync has a taskqueue module that it uses to queue up
transactions so that they are *all* run in a single, dedicated thread.

> More complex is the integration with sqlalchemy session handling.
> 
> As an example with Nevow:
> - a thread retrieve an object from the database
> - another thread modify the object
>
> It would be much simple if the two operations occur in the same thread
> (this require to run renderHTTP or locateChild in a separate thread but
> I ignore if this is safe).

Again, the two operations *do* run in the same thread under sAsync, as
do all other SQLAlchemy operations that are run via methods of
AccessBroker. All you have to do is decorate the method with @transact
and it will run via the queue and the dedicated thread.

So, you may not want to re-invent the wheel on this one. By the way, I
try to be responsive to user comments, ideas, and patches. Some have
already improved sAsync quite a bit.

Best regards,
Ed Suominen
Developer of sAsync: http://foss.eepatents.com/sAsync