[Twisted-Python] SQLAlchemy integration

[Manlio Perillo]

Ed Suominen ha scritto:
>>>> 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?
> 

My original motivation was to have an interface compatible with adbapi.

> 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.
> 

So sAsync uses only one 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. 


In sAsync I do not like the idea of startup method to initialize tables.

I would like to define tables where I want, so that I:
1) can create the tables on the database with a dedicated script
2) can import tables from one package to another, being able to do some
   modifications (if I need it).

> By the way, I
> try to be responsive to user comments, ideas, and patches. Some have
> already improved sAsync quite a bit.
> 


Regards  Manlio Perillo