[BangPypers] Simple python database library
noufal at gmail.com
Thu Mar 4 03:38:45 CET 2010
You could use the sql builder component of sql alchemy and skip the
orm part. The web.db part of web.py might work as well.
On 3/3/10, Dhananjay Nene <dhananjay.nene at gmail.com> wrote:
> On Wed, Mar 3, 2010 at 6:51 PM, steve <steve at lonetwin.net> wrote:
>> On 03/03/2010 04:36 PM, Dhananjay Nene wrote:
>>> Looking for a simple opensource python database library
>>> Objectives :
>>> - Should work at a level of abstraction above DB-Api. I should not have
>>> change code generally except for changing database configuration
>>> - Should be able to write code independent of the database (except where
>>> SQL itself was to be different in which case thats beyond the library's
>>> - Should support most reasonably popular databases (I am looking
>>> for MySQL but at least Postgres, SQL Server and Oracle support will be
>> All of that is available in popular ORMs. I prefer SQLObject to
>> Could you elaborate a bit on why an ORM would not be suitable ?
> I need to build some simple relational database access over 2-3 tables in a
> utility program. While it is quite solvable through ORM, the fairly limited
> scope and nature of database access does not require the capabilities of a
> full blown ORM. I use SQLAlchemy in my day job and I like it. Its just that
> I wouldn't want to introduce a dependency on a much bigger toolset
> especially when a smaller one could suffice.
>> - Abstractions should be at a relational level. Thus any ORMs are out of
>>> ehe .. ORM == Object /Relational/ Mapper. What do you mean by
>> "Abstractions should be at a relational level" ?
> I meant the API should reflect cursors, sqlcommands etc (not objects,
> relationships, inheritance etc.). Having said that I realise "at a
> relational level" was not the most appropriate wording.
>> I have found ADODb for Python so far. Looking for additional
>>> anydbm ? ( http://docs.python.org/library/anydbm.html ), of course that
>> though is not relational.
> Thanks for the tip. It got me thinking whether I could just choose to use it
> instead. Thats still a thought under progress.
>> A quick google OTOH gives me this:
>> Also, the little that i read online, I see that at least in theory all
>> python DBI should follow: http://www.python.org/dev/peps/pep-0249/
>> ...which if is also true in practice takes care of concerns you might have
>> about cross DB API.
> Thats not how I have seen it work. For example mysql prepared sql uses "%s"
> whereas others use "?". The database connection parameters are actually
> different between different databases. SQLAlchemy works with and deals with
> these issues. For example it has separate derived classes per database to
> handle some of these variations. Also it uses a connection URI to skip over
> the differences in the connection parameter differences. (The URI is always
> a string - even if the string itself is composed quite differently .. thus
> the code which uses the URI doesn't have to change even when the connection
> parameters change). So essentially what I am looking for (being the lazy
> person I am) is if someone has done this hard work of abstracting away the
> database dbapi implementation differences :)
>> - steve
>> random non tech spiel: http://lonetwin.blogspot.com/
>> tech randomness: http://lonehacks.blogspot.com/
>> what i'm stumbling into: http://lonetwin.stumbleupon.com/
> blog: http://blog.dhananjaynene.com
> twitter: http://twitter.com/dnene http://twitter.com/_pythonic
> BangPypers mailing list
> BangPypers at python.org
Sent from my mobile device
More information about the BangPypers