SQLObject or SQLAlchemy?

J

John Salerno

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.
 
A

Adam Jones

John said:
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.
 
J

John Salerno

Adam said:
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?
 
M

metaperl

John said:
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/tutorial.myt#tutorial_schemasql_table_relationships

but when you have to make a call to relation as well:
http://www.sqlalchemy.org/docs/tutorial.myt#tutorial_orm_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.

Just my 2 cents.
 
M

metaperl

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.
 
B

Bruno Desthuilliers

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.
 
A

Adam Jones

John said:
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.
 
J

Jorge Vargas

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.
 
J

Jorge Godoy

Jorge Vargas said:
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.
 
B

Bruno Desthuilliers

Jorge said:
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...
 
L

lazaridis_com

John said:
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)
 
B

Bruno Desthuilliers

lazaridis_com said:
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.
 
L

lazaridis_com

Ο/Η Bruno Desthuilliers έγÏαψε:
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.
 
B

Bruno Desthuilliers

lazaridis_com said:
Ο/Η Bruno Desthuilliers έγÏαψε:

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.
 
L

lazaridis_com

Bruno said:
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

..
 
A

alex23

lazaridis_com said:
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
 
B

Bruno Desthuilliers

lazaridis_com said:
...

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".
 
L

lazaridis_com

alex23 said:
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

..
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

SQLAlchemy - web framework ? 4
using SQLalchemy 0
SQLObject 1.4.0 0
SQLObject 1.0.0 0
SQLObject 1.0.1 0
sqlalchemy: delete() on m:n-relationship 0
SQLObject 1.1.0 0
SQLObject 0.15.0 0

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top