Support for CouchDB
Rawlins
Do we have support for CouchDB with SQlAlchemy? Can't seem to find
much information anywhere so I'm guessing not, just thought I would
check.
Thanks,
Robert
Diez B. Roggisch
The "SQL" in SQLAlchemy pretty much says it all. The whole way CouchDB and
RDBMS operate differs in so many respects that a sensible abstraction for both
of them makes no sense without it being leaky as the Deep Water Horizon oil
well...
For example, views in couchdb have to be persistent to be effective, whereas
the power of RDMBS is to be able to deal reasonably well with ad-hoc build
queries. Transactions and normalization are other problematic topics...
Diez
Michael Bayer
There's a long term plan to allow plugins that would provide attribute instrumentation and Session persistence services to objects that are persisted by a non-SQL database. Such a plugin would need to be written by a third party for each database backend and querying would also be an ad-hoc affair. So there's a notion of it but nothing is happening on that front right now.
>
> Thanks,
>
> Robert
>
> --
> You received this message because you are subscribed to the Google Groups "sqlalchemy" group.
> To post to this group, send email to sqlal...@googlegroups.com.
> To unsubscribe from this group, send email to sqlalchemy+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
>
Rawlins
Thanks for the info, i did expect that to be the case! I can
understand that the architecture is indeed very different.
As an extension to my question then, which DBMS would you guys
recommend for stability. We have a small embedded platform which has
an unreliable power source. We're currently using SQLite which appears
to work pretty well, is that something you would recommend? or is
there something else even simpler and more robust?
Cheers,
Robert
phrr...@googlemail.com
SQLite virtual tables. Although apsw cannot be used directly by
SQLAlchemy (as it is not dbapi compliant), you can pass an apsw
connection to pysqlite connect() and then use that connection as a
SQLAlchemy engine. I did some minimal work on a thin DBAPI
compatibility layer on top of apsw and the initial results were
encouraging but I have not been able to allocate any further time to
it. I am not far enough in to know if it is a great idea that will
work or an incredibly dumb one that has no chance of working!
So if you want to do some hacking about with create_engine(creator =
lambda ...) then you may just be able to get couchdb up and running
with SQLAlchemy via apsw. If you try it, let me know how you get on.
pjjH
Michael Bayer
On Aug 25, 2010, at 11:16 AM, Rawlins wrote:
> Hello Guys,
>
> Thanks for the info, i did expect that to be the case! I can
> understand that the architecture is indeed very different.
>
> As an extension to my question then, which DBMS would you guys
> recommend for stability. We have a small embedded platform which has
> an unreliable power source. We're currently using SQLite which appears
> to work pretty well, is that something you would recommend? or is
> there something else even simpler and more robust?
sqlite is a very good choice. Anecdotally, a venerable old database like BerkleyDB might be the "even simpler but still very solid" kind of choice, or maybe Tokyo Cabinet.
Chris Withers
>
> There's a long term plan to allow plugins that would provide attribute instrumentation and Session persistence services to objects that are persisted by a non-SQL database.
I guess at this point you'd need to drop 'SQL' from 'SQLAlchemy' ;-)
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk