= Research =
[[Relational database comparison]]
[[Database abstraction layers comparison]]
Using a Python based ORM wont tie the data just to python. any language should be able to access the db just fine. However, they wouldn't have access to pythons orm layer. Since I haven't used a true orm before I'm not certain exactly how it will effect our table relationships but I don't believe they wont make some sense in a relational way. Not that I'm saying we should use it but a quick google search started to bring up things like this [http://pecl.php.net/package/python php python package]. so there may be some hope for even using the orm layer but how complex would we really want to make it! And of course there is always the option of just using an orm and building similar objects in the new language. --[[User:AaronS|AaronS]] 03:30, 26 March 2009 (UTC)
== Database Abstraction Layer ==
I asked this question on [http://stackoverflow.com/questions/679806/what-are-the-viable-database-abstraction-layers-for-python StackOverflow].
=== <strike> CouchDB </strike> ===
http://code.google.com/p/couchdb-python/
[http://pylonshq.com/ Pylons] took the time to be able to use it.
This is not a db abstraction layer and not even a relational db.
=== DB-API ===
http://wiki.python.org/moin/DatabaseProgramming/
Python has an API to make it easy to move from one SQL-based DB to another called DB-API. Each DB may have multiple different modules available for it. If we settle on this solution then we should do some quick searches to make sure we pick the right modules.
*MySQL: Yes [http://sourceforge.net/projects/mysql-python MySQLDB] used by SQLAlchemy
*SQLite: Yes [http://www.python.org/doc/2.5.2/lib/module-sqlite3.html sqlite3] (included in Python 2.5 or greater) [http://oss.itsystementwicklung.de/trac/pysqlite pysqlite] both used by SQLAlchemy
*BSDDB: No. The DB-API looks to be only for relational dbs.
*ORM (Object Relational Mapper): no
"While all DB-API modules have identical APIs (or very similar; not all backends support all features), if you are writing the SQL yourself, you will probably be writing SQL in a product-specific dialect, so they are not as interchangeable in practice as they are in theory." [http://stackoverflow.com/questions/679806/what-are-the-viable-database-abstraction-layers-for-python kquinn]
=== <strike> Django </strike> ===
http://www.djangoproject.com/
Django also provides DB independence, but is geared towards web deployment:
"Django developed its ORM (and template language) from scratch. While that may have been a pragmatic decision at the time, Python now has SQLAlchemy, a superior database layer that has gained a lot of momentum. '''Django’s in-house ORM lacks multiple database support''', and forces constraints on your database models (e.g. that every database table must have a single, integer primary key). If you choose Django, your project gains a near-inseparable dependency on Django’s ORM and database requirements." [http://marcuscavanaugh.com/blog/python-web-framework-advice/ marcus cavanaugh 2009]
Django's DB abstraction probably isn't a good fit. While powerful I doubt any projects are using it outside of Django.
===<strike> pydo </strike>===
[http://skunkweb.sourceforge.net/pydo.html pydo]
doesn't look viable and looks like limited users and documentation. tied to a webframework.
=== SQLAlchemy ===
http://www.sqlalchemy.org/
*MySQL: Yes
*SQLite: Yes
*BSDDB: No.
[http://www.sqlalchemy.org/docs/05/dbengine.html#supported-dbapis supported dbs]
*ORM (Object Relational Mapper): yes but doesn't force it.
*mulitple database support?: yes [http://www.sqlalchemy.org/ source]
*Viability: Last release was January 24, 2009. They seem to have an established development team and user base. Project appears to be 3 years old,
"SQLAlchemy is designed to operate with a DB-API implementation built for a particular database" [http://www.sqlalchemy.org/docs/05/intro.html#api-reference source]
"SQLAlchemy, widely considered to be the best Python ORM available. SQLAlchemy includes multiple database support and just about any crazy combination of database requirements needed, and it handles ORM very well — yet it also allows you to provide raw SQL as needed." [http://marcuscavanaugh.com/blog/python-web-framework-advice/ marcus cavanaugh 2009]
=== SQLObject ===
http://www.sqlobject.org/
*MySQL: yes
*SQLite: yes
*BSDDB: no
[http://www.sqlobject.org/SQLObject.html#requirements requirements]
*ORM (Object Relational Mapper): yes this is what sqlobject is all about.
*mulitple database support?: ?
*Viability: Last release was 2008-12-08, 7 developers on the project. couldn't find old release dates but first was posted 2003-04-09. link to wiki is broken which isn't the best sign but we've all had those times before...
[http://www.sqlobject.org/SQLObject.html#compared-to-other-database-wrappers comparison]
[http://pylonshq.com/ Pylons] took the time to be able to use it.
=== Storm ===
https://storm.canonical.com/
*MySQL: yes
*SQLite: yes
*BSDDB: no
*ORM (Object Relational Mapper): yes
*mulitple database support?: yes
*Viability: currently developed. seems like a fairly good site with some documentation. The bigest drawback is that the project is only a year old. a pro is that it may be easier to use than sqlalchemy.
=== Discussion ===
