On Fri, Mar 5, 2010 at 12:49 PM, Dhananjay Nene <dhananjay.n...@gmail.com>wrote:
> I've decided to go ahead with SQLAlchemy even though that was not my > favourite. FWIW I'm just documenting my thoughts : > > Cons : Why I would've not preferred SQL Alchemy > a. Dependency into a large full function package like sqlalchemy which just > does a ton of stuff. I didn't need a ton of features .. just needed > something basic. > b. I was looking for something that worked at a ODBC/JDBC level > abstraction. Python DBAPI is actually a good candidate but for the fact it > doesn't really work cross database > > Pros : Why I decided to go ahead with SQLAlchemy > a. Already use it. So am familiar with it. > b. It is just too slick and polished a product. > c. It does offer relational abstractions. eg. Table (even though the > default, most often used mechanism is with model objects). The entire model > layer I really am not interested in, but SQLAlchemy does give me the > abstractions for table, connections etc. > d. Did not find a widely used competing candidate. Just not sure how widely > used and thus regularly tested adodb for python is - though did not have any > specific qualms against that particular package. > > Thanks for all the suggestions. I evaluated them all and the suggestions > were very helpful fodder for the process. > > Aaargh, few hours after I decide that I run into this. From an intent perspective it is much more consistent with what I was looking for - http://www.pauldeden.com/2009/01/edendb-thin-flexible-and-fast-python.html The sample usage is listed here http://code.google.com/p/edendb/ -- -------------------------------------------------------- blog: http://blog.dhananjaynene.com twitter: http://twitter.com/dnene _______________________________________________ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers
