mardiros <mardiros@laposte.net> writes:

I am looking in Storm for the moment. I have copy the driver in the twisted-integration, but it tries with the both driver pymssql and adodbapi, and i think only the mxodbc worked.

Now i execute deferred query  with a modified one, and it work's fine.

I will try orm feature now :-)

While it looks like there's some specific Twisted integration work going on in a branch, from what I can see, the current mechanisms you will need to use Storm with Twisted are the same as those you would need to use to use SQLAlchemy with Twisted, so if you like the latter, I don't see a big reason to switch. That is, defer the ORM related (blocking) operations to their own thread (ala deferToThread), and remember to detach any ORM objects being returned to Twisted from the ORM itself. With SQLAlchemy you'd call expunge() on the objects or expunge_all() on the session. If you need to make changes and save them, you would need to re-attach the objects to a session before flushing to the database (also in a dedicated thread). With SQLAlchemy, this can be done with add() or add_all() on a session. I suspect you could wrap this behavior up in a fairly simple wrapper class, without necessarily needing a third party library or package. For me, I find SQLAlchemy very impressive, and I think it's flexibility in defining how and when the ORM accesses the database and clear management of the association of objects to sessions to be helpful in this sort of integration. For example, you could still work with defined relations at the object level as long as you ensured that they were eager loaded while still running in the SA thread. That could either be by disabling lazy loading entirely for specific relations, or by forcing an eager load for specific queries through the eagerload() option. It's also not quite clear what sort of transactions are involved from your original post. Although you mention preferring an ORM, if you just need to issue some basic queries/updates against an existing database schema, you might at least also consider straight SQL. In that case, SQLAlchemy's SQL layer can still provide a lot of support (to avoid writing raw SQL) but not bring in all the ORM overhead. -- David PS: Even if you found a current copy of sAsync, based on some comments the author posted in a thread back in March, I don't think sAsync supports the ORM features of SQLAlchemy, but just the SQL layer.

mardiros <mardiros@laposte.net> writes:

I am looking in Storm for the moment. I have copy the driver in the twisted-integration, but it tries with the both driver pymssql and adodbapi, and i think only the mxodbc worked.

Now i execute deferred query  with a modified one, and it work's fine.

I will try orm feature now :-)

While it looks like there's some specific Twisted integration work going on in a branch, from what I can see, the current mechanisms you will need to use Storm with Twisted are the same as those you would need to use to use SQLAlchemy with Twisted, so if you like the latter, I don't see a big reason to switch. That is, defer the ORM related (blocking) operations to their own thread (ala deferToThread), and remember to detach any ORM objects being returned to Twisted from the ORM itself. With SQLAlchemy you'd call expunge() on the objects or expunge_all() on the session. If you need to make changes and save them, you would need to re-attach the objects to a session before flushing to the database (also in a dedicated thread). With SQLAlchemy, this can be done with add() or add_all() on a session. I suspect you could wrap this behavior up in a fairly simple wrapper class, without necessarily needing a third party library or package. For me, I find SQLAlchemy very impressive, and I think it's flexibility in defining how and when the ORM accesses the database and clear management of the association of objects to sessions to be helpful in this sort of integration. For example, you could still work with defined relations at the object level as long as you ensured that they were eager loaded while still running in the SA thread. That could either be by disabling lazy loading entirely for specific relations, or by forcing an eager load for specific queries through the eagerload() option. It's also not quite clear what sort of transactions are involved from your original post. Although you mention preferring an ORM, if you just need to issue some basic queries/updates against an existing database schema, you might at least also consider straight SQL. In that case, SQLAlchemy's SQL layer can still provide a lot of support (to avoid writing raw SQL) but not bring in all the ORM overhead. -- David PS: Even if you found a current copy of sAsync, based on some comments the author posted in a thread back in March, I don't think sAsync supports the ORM features of SQLAlchemy, but just the SQL layer.