database wrapper ?
Stef Mientki
Until now I used a simple wrapper around pysqlite and pyodbc to manage
my databases.
Now I'm looking for a better solution,
because I've to support a (for this moment) unknown database,
and I'm not the one who will choose the database.
Googling, I found SQLalchemy,
which looks quit good.
But as I only want to choose once,
I googled for "SQLalchemy alternatives",
but it didn't find many answers.
(Storm / Grok are of no interest, because manipulating the structure of
the database is a key issue).
Is SQLalchemy the best / most popular database wrapper ?
Are there any alternatives ?
I don't know if it matters:
but for the short term it's only for desktop applications,
but in the future I'll certainly want to move to web based databases.
thanks,
Stef
Chris Rebert
> hello,
>
> Until now I used a simple wrapper around pysqlite and pyodbc to manage my
> databases.
> Now I'm looking for a better solution,
> because I've to support a (for this moment) unknown database,
> and I'm not the one who will choose the database.
>
> Googling, I found SQLalchemy,
> which looks quit good.
>
> But as I only want to choose once,
> I googled for "SQLalchemy alternatives",
> but it didn't find many answers.
> (Storm / Grok are of no interest, because manipulating the structure of the
> database is a key issue).
>
> Is SQLalchemy the best / most popular database wrapper ?
> Are there any alternatives ?
SQLObject is also probably worth looking at -- http://www.sqlobject.org/
Cheers,
Chris
--
Follow the path of the Iguana...
http://rebertia.com
Stephen Hansen
Googling, I found SQLalchemy,
which looks quit good.
SQLAlchemy is very good. I'm very slowly migrating our entire codebase to it.
But as I only want to choose once,
I googled for "SQLalchemy alternatives",
but it didn't find many answers.
(Storm / Grok are of no interest, because manipulating the structure of the database is a key issue).
There's a few other alternatives-- if you google "Python ORM" you'll find a lot more, and PyPi might have a list. But IMHO, SQLAlchemy is the best of breed so far. Its very, very flexible and doesn't really impose on you with any rules about how you must do things.
Storm's not bad, don't get me wrong!
But one question on your requirements: manipulating the structure of the database. How so? If you mean that you want to be able to modify the object wrapper to change some field of a table and have that change propagated to the database layer... then SQLAlchemy doesn't support that. If you add new tables it'll create them, and it MIGHT add new columns or indexes if you add them after and it notices they aren't there... but I'm not entirely sure on that. Never came up in my SQLAlchemy work yet. I've mostly just been adding tables and doing create_all() to get the new ones in.
--S
Ben Finney
> Is SQLalchemy the best / most popular database wrapper ?
In my opinion, yes it's the best. It gives a good ORM (letting you
treat your data as objects and have them persistently stored in the
database), while still allowing all the power and flexibility of full
SQL whenever you need it; and a continuum of options in between (e.g.
a helpful query builder toolkit).
--
\ “We must respect the other fellow's religion, but only in the |
`\ sense and to the extent that we respect his theory that his |
_o__) wife is beautiful and his children smart.” —Henry L. Mencken |
Ben Finney
andrew cooke
SQLAlchemy is the best SQL library I have ever used.
But it may depend on who you ask. For me, what makes SQLAlchemy so
good is the way it allows you to use SQL from within Python. I have
used the ORM side, and that's fine, but it's the way that it doesn't
get in the way of "just" SQL that make it so good. If I had to choose
a second reason why it's so good it would be the way it emphasises
metadata - it will use table definitions from the database, and it
will let you define schema yourself (in fact, it's an excellent way of
defining complex schema in a platform-independent fashion).
The main drawback is that it is rather complex. If something doesn't
work, it can be tricky to work out why. On the other hand, the
documentation is good, and the support (on google groups) is good too
(a developer always replies within 24 hours in my experience).
It does expect you to know SQL - it doesn't try to hide SQL at all.
Whether that is good or bad depends on your POV I guess.
I wish all DB solutions were like this - my hope is that EmpireDB will
do the same for Java, but it's too early to tell...
Andrew
andrew cooke
> I wish all DB solutions were like this - my hope is that EmpireDB will
> do the same for Java, but it's too early to tell...
Hmmm - I should correct the above. I had assumed EmpireDB was new,
because it's an Apache Incubator project, but now I look at their site
I see it's actually been around for years. I need to try it out...
Sorry about the error,
Andrew
Stef Mientki
> On Sun, Feb 1, 2009 at 2:56 PM, Stef Mientki <stef.m...@gmail.com> wrote:
>
>> hello,
>>
>> Until now I used a simple wrapper around pysqlite and pyodbc to manage my
>> databases.
>> Now I'm looking for a better solution,
>> because I've to support a (for this moment) unknown database,
>> and I'm not the one who will choose the database.
>>
>> which looks quit good.
>>
>> I googled for "SQLalchemy alternatives",
>> but it didn't find many answers.
>> (Storm / Grok are of no interest, because manipulating the structure of the
>> database is a key issue).
>>
>>
>
> SQLObject is also probably worth looking at -- http://www.sqlobject.org/
>
> Cheers,
> Chris
>
>
but I guess it's difficult to judge, without trying them all,
most information is quit fragmented.
For now, I've the "feeling" the following arguments are valid:
(If I'm telling something completely wrong, someone will correct me ;-)
positive for SQLAlchemy
- SQLObject is obsolete. Turbo Gears has replaced SQLObject with
SQLAlchemy.
- SQLAlchemy is better / faster supported than SQLObject.
- SQLAlchemy is faster
positive for SQLObject
- supports Sybase (which is also obsolete, but still used in my environment)
equal for both
- SQLObject is much easier, but if you put Elixer on top of SQLAlchemy,
you've about the same easy interface.
As we've planned to replace Sybase in the not too far future, the choice
for me seems clear.
thanks you al,
cheers,
Stef
Martin
2009/2/1 Stef Mientki <stef.m...@gmail.com>:
> Googling, I found SQLalchemy,
> which looks quit good.
sqlalchemy was always enough for my needs, I recently found elixir
which is yet another wrapper around sqlalchemy. I haven't played too
much with it but it seems there are a couple of nice things, that is
elixir makes using sqlalchemy even easier.
hth
martin
--
http://soup.alt.delete.co.at
http://www.xing.com/profile/Martin_Marcher
http://www.linkedin.com/in/martinmarcher
You are not free to read this message,
by doing so, you have violated my licence
and are required to urinate publicly. Thank you.
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
Mike Orr
> Googling, I found SQLalchemy,
> which looks quit good.
> SQLAlchemy is very good. I'm very slowly migrating our entire codebase to it.
>
>
>
> But as I only want to choose once,
> I googled for "SQLalchemy alternatives",
> but it didn't find many answers.
> (Storm / Grok are of no interest, because manipulating the structure of the database is a key issue).
> There's a few other alternatives-- if you google "Python ORM" you'll find a lot more, and PyPi might have a list. But IMHO, SQLAlchemy is the best of breed so far. Its very, very flexible and doesn't really impose on you with any rules about how you must do things.
> Storm's not bad, don't get me wrong!
> But one question on your requirements: manipulating the structure of the database. How so? If you mean that you want to be able to modify the object wrapper to change some field of a table and have that change propagated to the database layer... then SQLAlchemy doesn't support that. If you add new tables it'll create them, and it MIGHT add new columns or indexes if you add them after and it notices they aren't there... but I'm not entirely sure on that.
engine.execute("ALTER TABLE ...")
However, this may confuse ORM objects already in memory as well as
transactions, so clear these out both before and afterward. The
syntax is database specific. MySQL can add and delete columns and
change a column's type. SQLite can only rename tables. However, your
ORM objects won't know about the new columns unless you reinitialize
the Table objects and mapper with autoloading. So it's best to modify
the schema in a standalone program that does not use the ORM.
As for modifying the columns in the Table objects and propagating the
changes to the database, you can't do that. You have to execute
"ALTER TABLE" as a string command. SQLAlchemy would have to add a
whole new layer to deal with alternations at the Table or SQL builder
level, and in the end they're still database specific.
Christian
> Is SQLalchemy the best / most popular database wrapper ?
> Are there any alternatives ?
As others have confirmed, SQLAlchemy is far and away the most popular
Python ORM.
Another one to have a look at though is Dejavu (http://www.aminus.net/
dejavu). The user community isn't nearly as large but the software
itself is quite good. One of its distinctives is that you can treat
multiple disparate data stores as one cohesive relational structure.
It also isn't bound to SQL databases. There are storage
implementations included for file system, Shelve and in-memory
storage. The 2.0 alpha code in trunk also has a memcached storage
implementation.
HTH,
Christian
http://www.dowski.com
Christian
> One of its distinctives is that ...
Not sure how I forgot this, but Dejavu also lets you write your
datastore queries in a LINQ-like syntax. Robert Brewer, the author,
is giving a talk [1] about it at this year's PyCon in the US.
Christian
http://www.dowski.com
[1] http://pycon.org/2009/conference/talks/#proposal_link_91