On 10/25/05, <b class="gmail_sendername">Jim McCoy</b> <<a href="mailto:jim.mccoy@gmail.com">jim.mccoy@gmail.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
If you are going to use sqlite/sqlobject as an embedded db (as the<br>original poster suggested) then you are probably better off just<br>writing your own deferred wrapper for your sql ops. Treat your db<br>access (at least your select/set/update ops on your SQLObject schema
<br>classes) as you would any other blocking operation; if your db is not<br>huge you can probably be more productive by applying twisted to other<br>parts of your application.<br><br>Since you are using sqlite as an embedded db you are not going to get
<br>any benefit from the connection marshalling and threading that seems<br>to be t.enterprise.adbapi's raison d'etre. Rather than digging into<br>the adbapi docs or looking at axiom you would probably be better<br>served by just building a wrapper around your db that returns
<br>deferred's for the various db CRUD operations.<br><br>Jim</blockquote><div><br>
I've been using an in-memory sqlite database with trivial amounts of
data and actually have been treating it as non-blocking. You wouldn't
defer moving around python data structures, and in my experience, for a
small in-memory sqlite database, you get better performance using it
synchronously inline.<br>
</div><br></div><br>