[Twisted-Python] AsyncQueue is still unavailable
db3l.net at gmail.com
Fri Jun 19 15:05:44 EDT 2009
mardiros <mardiros at 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.
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.
More information about the Twisted-Python