468,116 Members | 2,222 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,116 developers. It's quick & easy.

SQLObject or SQLAlchemy?

Are there any major differences between these two? It seems they can
both be used with TurboGears, and SQLAlchemy with Django. I'm just
wondering what everyone's preference is, and why, and if there are even
more choices for ORM.

Thanks.
Aug 31 '06 #1
20 3662

John Salerno wrote:
Are there any major differences between these two? It seems they can
both be used with TurboGears, and SQLAlchemy with Django. I'm just
wondering what everyone's preference is, and why, and if there are even
more choices for ORM.

Thanks.
Currently most of my work is done in SQLObject because it was stable
when I started the project I am on. In all the cases I can think of for
a new project I would use SQLAlchemy. Even for projects where SO
supports the relational model I am using I think SA's extra flexability
is worth the effort.

Aug 31 '06 #2
Adam Jones wrote:
I think SA's extra flexability
is worth the effort.
Thanks for the reply. Do you mean in the above quote that SA is a little
more complicated than SO?
Aug 31 '06 #3

John Salerno wrote:
Are there any major differences between these two? It seems they can
both be used with TurboGears, and SQLAlchemy with Django. I'm just
wondering what everyone's preference is, and why, and if there are even
more choices for ORM.
I just finished surfing both websites last night myself and here is
what I glean

-- I dont see why SQLObject could not be used with Django

-- SQLAlchemy is not just an ORM. It can be used that way. I dont know
why you have to explicitly tell it about related tables twice though.
You do it the first time when defining table metadata:
http://www.sqlalchemy.org/docs/tutor..._relationships

but when you have to make a call to relation as well:
http://www.sqlalchemy.org/docs/tutor..._relationships

It would seem that one or the other is enough and having to do both is
redundant... continuing with the comparison

-- SQLObject makes it clear that it only has support for tables with a
single-column primary key

-- tha can both do self-joins

-- SQLAlchemy has support for connection pooling

-- ORMS get slow when you need to load a lot of records. SQLAlchemy has
usage modes to load massive data sets when the job calls for it.
>
Thanks.
Just my 2 cents.

Aug 31 '06 #4

John Salerno wrote:

Thanks for the reply. Do you mean in the above quote that SA is a little
more complicated than SO?
Don't be afraid to download them and try their respective tutorials.
Each one would take about an hour and then you'd have a feel for
yourself. I agree with adam that SQLAlchemy has far more features and
flexibility.

SQLObject would be very great and convenient if you were throwing up a
website that you knew would never require high volumne.

SA does have an IRC group. It's not incredibly lively but at least
there is one.

Aug 31 '06 #5
John Salerno a crit :
Are there any major differences between these two?
Yes. SQLAlchemy is, mainly, a very higher-level DB-API that makes
working with a RDBMS almost transparent (no embedded SQL unless you
really wants to) without trying to pretend there's no RDBMS nor forcing
you into ORM mode. ORM facilities are built on top of this.
It seems they can
both be used with TurboGears, and SQLAlchemy with Django. I'm just
wondering what everyone's preference is, and why,
I'd say SQLAlchemy. I've used Django's ORM (pre 'magic-removal' version)
and played a bit with SQLObject, but after an afternoon playing with
SQLAlchemy and browsing the doc, I don't wan't to hear of them anymore.
and if there are even
more choices for ORM.
There is. But nothing as exceiting as SQLAlchemy IMHO. Now FWIW,
installing and testing is probably the quickest way to make your own
opinion.

Aug 31 '06 #6

John Salerno wrote:
Adam Jones wrote:
I think SA's extra flexability
is worth the effort.

Thanks for the reply. Do you mean in the above quote that SA is a little
more complicated than SO?
Yes, it is. To avoid the technical issues involved the complication can
be summarized as: SQLAlchemy implements the Data Mapper pattern, of
which the Active Record pattern (which SQLObject implements) is a
subset.

SO makes a few assumptions about your tables (like that it will have
single immutable primary keys for all tables) which make it difficult
to work with an existing database. It also does not have the ability to
compile multiple queries into a single unit of work for processing, at
least not on the same level that SA does. Given that SA can support
more complex data models, is better for supporting pre-existing
databases, and usually is faster. After you have learned it you have a
better tool all around. That said it is more complicated, and if what
you are doing is not high traffic and does not require extremely
complex data models SO is still an excellent choice.

Aug 31 '06 #7
I think this post by the author of SQLAlchemy perfectly summarizes the
differences between the two ORMs:

http://article.gmane.org/gmane.comp....emy.user/1072/

--
mvh Bjrn
Sep 1 '06 #8
"BJörn Lindqvist" <bj*****@gmail.comwrites:
I think this post by the author of SQLAlchemy perfectly summarizes the
differences between the two ORMs:

http://article.gmane.org/gmane.comp....emy.user/1072/
And ActiveMapper is working to some extent better than it was by the time of
the post :-)

--
Jorge Godoy <jg****@gmail.com>
Sep 1 '06 #9
On 8/31/06, John Salerno <jo******@nospamgmail.comwrote:
Are there any major differences between these two? It seems they can
both be used with TurboGears, and SQLAlchemy with Django. I'm just
wondering what everyone's preference is, and why, and if there are even
more choices for ORM.
they use two approach to the same problem.

SO tries to tide each object to a table while
SA lets you do the mapping.

so each one has it's pros and cons.

for example SA wins at using an existing db
but SO wins at not worring about the db structure

SO demands tables to have a primary single col int key which is manage
by the API, while SA lets you mess with it a bit more.

so you could say that SO takes care about many things so you don't
have to worry about them, or other may say SO is too intrusive.

In my experience SO is great for new projects and if you don't want to
mess/optimize with the actual SQL queries (which is great for an ORM
because IMO that is the main goal of ORMing)

Now if you need to mess a lot with the db (either a existing one or
need optimized queries) then SA is worth the extra effort, since
making those things on SO is going uphill.
Thanks.
--
http://mail.python.org/mailman/listinfo/python-list
Sep 1 '06 #10
"Jorge Vargas" <jo**********@gmail.comwrites:
for example SA wins at using an existing db
but SO wins at not worring about the db structure
That's not entirely true. Some things are impossible with SQL Object alone.
You have to, at least, make use of sqlbuilder. And these aren't hard things,
mind you: performing joins, filtering data accordingly to N:N relationships,
etc.
SO demands tables to have a primary single col int key which is manage
by the API, while SA lets you mess with it a bit more.
SQL Objects allows for an str primary key as well. You're not tied to
integers only.
so you could say that SO takes care about many things so you don't
have to worry about them, or other may say SO is too intrusive.
As has been said, it's approach to mapping the database is a subset from SQL
Alchemy. This makes it better in some cases -- simpler, at least -- and worse
in other cases -- inefficient, impossible to use, etc.
In my experience SO is great for new projects and if you don't want to
mess/optimize with the actual SQL queries (which is great for an ORM because
IMO that is the main goal of ORMing)
It is good for simple projects. If you need more performance then you'll have
lots of troubles optimizing things with SQL Object in mind. Also it will
force you to work directly on the database more often than SQL Alchemy to
squeeze more performance from it.

I'm converting an application from SQL Object -- that's what I've been using
for a while -- to SQL Alchemy -- this will be my first production application
with it -- and I'm liking the possibilities and extendability of SQL Alchemy.

A lot of things that I did in the database are possible with my declarations
in SQL Alchemy, so I have a map that's more "real" with regards to what's in
the database.
Now if you need to mess a lot with the db (either a existing one or
need optimized queries) then SA is worth the extra effort, since
making those things on SO is going uphill.
It isn't too hard to use SA for simple things. I dare to say that with
ActiveMapper it is just a bit more verbose than SQL Object, but not too much.

--
Jorge Godoy <jg****@gmail.com>
Sep 1 '06 #11
Jorge Vargas wrote:
On 8/31/06, John Salerno <jo******@nospamgmail.comwrote:
>Are there any major differences between these two? It seems they can
both be used with TurboGears, and SQLAlchemy with Django. I'm just
wondering what everyone's preference is, and why, and if there are even
more choices for ORM.
they use two approach to the same problem.
I do not agree here. SLQObject tries to use a RDBMS for object
persistance, while SQLAlchemy's main goal is to provide a better
integration of RDBMS into Python - ORM features being just an optional
facility.
SO tries to tide each object to a table while
SA lets you do the mapping.

so each one has it's pros and cons.

for example SA wins at using an existing db
but SO wins at not worring about the db structure
Not worrying about the db structure ? Heck, why using a RDBMS then - if
what you want is object persistance, ZODB works just fine.

SQLAlchemy clearly exposes the RDBMS schema (you can either define the
schema in Python or use reflection), and gives you access to the full
power of SQL DBMS without having to do the embed-SQL-as-strings dance.

(snip)
In my experience SO is great for new projects
and if you don't want to
mess/optimize with the actual SQL queries (which is great for an ORM
because IMO that is the main goal of ORMing)
Disagreement here too. Even for relatively simple new projects,
SQLObject can be far too limited to take advantage of relational
paradigm. Try managing valued many-to-many associations with SQLObject -
which is a pretty simple and common requirement, and certainly not
"messing with the db".

SQLObject, while being a much better piece of software than what I could
come with by myself (been here, done that...), is IMVHO a wrong
solution. I mean, a RDBMS is not a persistence engine, it's a data
management tool. If you don't need a relational model, or if it doesn't
match your app's needs, then why use one when we have great OODBMS in
Python ?

My 2 cents...
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Sep 1 '06 #12
John Salerno wrote:
Are there any major differences between these two? It seems they can
both be used with TurboGears, and SQLAlchemy with Django. I'm just
wondering what everyone's preference is, and why, and if there are even
more choices for ORM.

Thanks.
You can review the Persit Case, which will shortly evaluate the stated
ORM's:

http://case.lazaridis.com/wiki/Persist

It is possibly of importance to remember some requirements which should
be relevant for an persistency mechanism targetting an OO language:

Requirements

* Uses standard OO Terminology on the API side
o free of SQL/Relational terminology for ORM Tools
* Transparency (minimal or no difference to standard objects of the
language)
o Inheritance
* Includes Automated Schema Evolution Support
o Development Schema Evolution (focusing on simplicity and
conveniency etc.)
o Production Schema Evolution (focusing on integrity,
stability etc.)
* Support Standard ODBMS API's
* Support of Standards within the language-domain (e.g. Python)

Sep 1 '06 #13
lazaridis_com wrote:
John Salerno wrote:
>Are there any major differences between these two? It seems they can
both be used with TurboGears, and SQLAlchemy with Django. I'm just
wondering what everyone's preference is, and why, and if there are even
more choices for ORM.

Thanks.

You can review the Persit Case, which will shortly evaluate the stated
ORM's:

http://case.lazaridis.com/wiki/Persist

It is possibly of importance to remember some requirements which should
be relevant for an persistency mechanism targetting an OO language:
RDBMS are not "persistency mechanism", they are data management tools.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Sep 1 '06 #14

Ο/Η Bruno Desthuilliers *γραψε:
lazaridis_com wrote:
John Salerno wrote:
Are there any major differences between these two? It seems they can
both be used with TurboGears, and SQLAlchemy with Django. I'm just
wondering what everyone's preference is, and why, and if there are even
more choices for ORM.

Thanks.
You can review the Persit Case, which will shortly evaluate the stated
ORM's:

http://case.lazaridis.com/wiki/Persist

It is possibly of importance to remember some requirements which should
be relevant for an persistency mechanism targetting an OO language:

RDBMS are not "persistency mechanism", they are data management tools.
possibly.

but this is not relevant, as the "Persist" case does not deal with
RDBMS.

Sep 1 '06 #15
lazaridis_com wrote:
Ο/Η Bruno Desthuilliers *γραψε:
>lazaridis_com wrote:
>>John Salerno wrote:
Are there any major differences between these two? It seems they can
both be used with TurboGears, and SQLAlchemy with Django. I'm just
wondering what everyone's preference is, and why, and if there are even
more choices for ORM.

Thanks.
You can review the Persit Case, which will shortly evaluate the stated
ORM's:

http://case.lazaridis.com/wiki/Persist

It is possibly of importance to remember some requirements which should
be relevant for an persistency mechanism targetting an OO language:
RDBMS are not "persistency mechanism", they are data management tools.

possibly.

but this is not relevant, as the "Persist" case does not deal with
RDBMS.
Then your post is irrelevant since there's a clear indication that the
OP question was about RDBMS integration in Python (hint: SQLObject and
SQLAlchemy both start with 'SQL').

good night.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Sep 4 '06 #16
Bruno Desthuilliers wrote:
lazaridis_com wrote:
Ο/Η Bruno Desthuilliers *γραψε:
lazaridis_com wrote:
John Salerno wrote:
Are there any major differences between these two? It seems they can
both be used with TurboGears, and SQLAlchemy with Django. I'm just
wondering what everyone's preference is, and why, and if there are even
more choices for ORM.

Thanks.
You can review the Persit Case, which will shortly evaluate the stated
ORM's:

http://case.lazaridis.com/wiki/Persist

It is possibly of importance to remember some requirements which should
be relevant for an persistency mechanism targetting an OO language:
RDBMS are not "persistency mechanism", they are data management tools.
possibly.

but this is not relevant, as the "Persist" case does not deal with
RDBMS.
Then your post is irrelevant since there's a clear indication that the
OP question was about RDBMS integration in Python (hint: SQLObject and
SQLAlchemy both start with 'SQL').
....

Of course it's relevant.

"I'm just wondering what everyone's preference is, and why, and if
there are even more choices for ORM."

The "persist case" evaluates python persistency systems (or
mechanisms), and will show my personal preference:

"Object Oriented Persistency Systems (this includes OODBMS,
Object-Relational-Mappers, and others)."

http://case.lazaridis.com/wiki/Persist

..

Sep 5 '06 #17
lazaridis_com wrote:
The "persist case" evaluates python persistency systems (or
mechanisms), and will show my personal preference:
Do you feel that evaluating-for-evaluation's-sake produces a more
measured understanding of the value of a product than that taken from
its use in, say, actual development?

-alex23

Sep 6 '06 #18
lazaridis_com wrote:
Bruno Desthuilliers wrote:
>lazaridis_com wrote:
>>Ο/Η Bruno Desthuilliers *γραψε:
lazaridis_com wrote:
John Salerno wrote:
>Are there any major differences between these two? It seems they can
>both be used with TurboGears, and SQLAlchemy with Django. I'm just
>wondering what everyone's preference is, and why, and if there are even
>more choices for ORM.
>>
>Thanks.
You can review the Persit Case, which will shortly evaluate the stated
ORM's:
>
http://case.lazaridis.com/wiki/Persist
>
It is possibly of importance to remember some requirements which should
be relevant for an persistency mechanism targetting an OO language:
RDBMS are not "persistency mechanism", they are data management tools.
possibly.

but this is not relevant, as the "Persist" case does not deal with
RDBMS.
Then your post is irrelevant since there's a clear indication that the
OP question was about RDBMS integration in Python (hint: SQLObject and
SQLAlchemy both start with 'SQL').
...

Of course it's relevant.
Of course not.
"I'm just wondering what everyone's preference is, and why, and if
there are even more choices for ORM."
You may not know it but the R in ORM stands for Relational, which
actually implies a RDBMS.
The "persist case" evaluates python persistency
Once again, it has nothing to do with persistency. I can use an ORM
connected to an in-memory SQLite db.
systems (or
mechanisms), and will show my personal preference:
I don't give a damn about your "personal preferences".

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Sep 6 '06 #19
alex23 wrote:
lazaridis_com wrote:
The "persist case" evaluates python persistency systems (or
mechanisms), and will show my personal preference:

Do you feel that evaluating-for-evaluation's-sake produces a more
measured understanding of the value of a product than that taken from
its use in, say, actual development?
I don't evaluate for "evaluating-for-evaluation's-sake", see the home
page of the project:

"The project selects Open Source Subsystems for integration into a
Coherent Software Production System. "
http://case.lazaridis.com/wiki

..

Sep 6 '06 #20

Bruno Desthuilliers wrote:
lazaridis_com wrote:
Bruno Desthuilliers wrote:
lazaridis_com wrote:
Ο/Η Bruno Desthuilliers *γραψε:
lazaridis_com wrote:
John Salerno wrote:
Are there any major differences between these two? It seems they can
both be used with TurboGears, and SQLAlchemy with Django. I'm just
wondering what everyone's preference is, and why, and if there areeven
more choices for ORM.
>
Thanks.
You can review the Persit Case, which will shortly evaluate the stated
ORM's:

http://case.lazaridis.com/wiki/Persist

It is possibly of importance to remember some requirements which should
be relevant for an persistency mechanism targetting an OO language:
RDBMS are not "persistency mechanism", they are data management tools.
possibly.

but this is not relevant, as the "Persist" case does not deal with
RDBMS.

Then your post is irrelevant since there's a clear indication that the
OP question was about RDBMS integration in Python (hint: SQLObject and
SQLAlchemy both start with 'SQL').
...

Of course it's relevant.

Of course not.
You are right.

It's not relevant for _you_.
"I'm just wondering what everyone's preference is, and why, and if
there are even more choices for ORM."

You may not know it but the R in ORM stands for Relational, which
actually implies a RDBMS.
....which is completely irrelevant to _me_.

Thus I'm looking for an ORM which decouples the "R" part nicely.
The "persist case" evaluates python persistency

Once again, it has nothing to do with persistency. I can use an ORM
connected to an in-memory SQLite db.
What _you_ do is not _my_ use case.
systems (or mechanisms), and will show my personal preference:

I don't give a damn about your "personal preferences".
_You_ are not the central part of this topic.

_I_ am not the central part of this topic.

The OP asked for "personal preferences":

"I'm just wondering what everyone's preference is, and why, and if
there are even more choices for ORM."

I present my personal preferences here:

http://case.lazaridis.com/wiki/Persist

nothing special.
..

Sep 6 '06 #21

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Oleg Broytmann | last post: by
3 posts views Thread by Daniel Nogradi | last post: by
3 posts views Thread by Oleg Broytmann | last post: by
reply views Thread by Oleg Broytmann | last post: by
4 posts views Thread by petr.jakes.tpc | last post: by
3 posts views Thread by bruce | last post: by
reply views Thread by Oleg Broytmann | last post: by
6 posts views Thread by didacticone | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.