PERSIST - SQLObject compatible layer for SQLAlchemy

[Ilias Lazaridis]

I was wondering how close could a SQLObject compatible API (fictional
name: ObjectAlchemy) placed on top of SQLAlchemy come to SQLObject.

I don't remember where, but someone had suggested this a few months ago
(development of SQLObject2 ORM layer based on SQLAlchemy, instead of
using http://sqlobject.org/sqlapi/). This suggestion sounded very
rational to me, but it seems the SQLObject team-lead has not followed
it.

Some people on the SQLObject list sayed that ActiveMapper comes already
as close to SQLObject as possible.[1] Is this true?

If so, what would be the reason to stay with SQLObject (seeing the
quite inactive project and the non-existent version SQLObject2 /
SQL-API version)?

A final question: Provides ActiveMapper all functionality of SQLObject,
even if not API compatible?

[1]
http://thread.gmane.org/gmane.comp.python.sqlobject/7033/focus=7033

.

[Jorge Vargas]

damn your comming to spam here too...

On 10/11/06, Ilias Lazaridis <il...@lazaridis.com> wrote:
>
> I was wondering how close could a SQLObject compatible API (fictional
> name: ObjectAlchemy) placed on top of SQLAlchemy come to SQLObject.
>

that is not possible because they are two different design patterns

> I don't remember where, but someone had suggested this a few months ago
> (development of SQLObject2 ORM layer based on SQLAlchemy, instead of
> using http://sqlobject.org/sqlapi/). This suggestion sounded very
> rational to me, but it seems the SQLObject team-lead has not followed
> it.
>
> Some people on the SQLObject list sayed that ActiveMapper comes already
> as close to SQLObject as possible.[1] Is this true?
>

sayed is not a word

Why don't you go read the code instead?
http://www.sqlalchemy.org/trac/browser/sqlalchemy/trunk/lib/sqlalchemy/ext/activemapper.py

SO and SA are two different approaches to solve the same problem

http://mail.python.org/pipermail/python-list/2006-September/359164.html
and google about the patterns
http://www.martinfowler.com/eaaCatalog/dataMapper.html
http://www.martinfowler.com/eaaCatalog/activeRecord.html

> If so, what would be the reason to stay with SQLObject (seeing the
> quite inactive project and the non-existent version SQLObject2 /
> SQL-API version)?
>

Can you please drop that
#1 TG is moving to SA
#2 the reason is flexibility
#3 saying that kind of things just make the people of SO look bad and
what you end up doing is working agains the project (or is that what
you want to)?

> A final question: Provides ActiveMapper all functionality of SQLObject,
> even if not API compatible?
>

no and it probably never will, why? because SO wraps the db, what
ActiveMapper does create the mapper table on very simple rules (read
each property = each row)

ActiveMapper is syntatically similar to SO in order to simplify the
migration but it will never be SO.

> [1]
> http://thread.gmane.org/gmane.comp.python.sqlobject/7033/focus=7033
>
> .
>
>
> >
>

[Ilias Lazaridis]

Jorge Vargas wrote:
> damn your comming to spam here too...

please change your tenor.

> On 10/11/06, Ilias Lazaridis <il...@lazaridis.com> wrote:
> >
> > I was wondering how close could a SQLObject compatible API (fictional
> > name: ObjectAlchemy) placed on top of SQLAlchemy come to SQLObject.
> >
> that is not possible because they are two different design patterns

don't think so, see below.

> > I don't remember where, but someone had suggested this a few months ago
> > (development of SQLObject2 ORM layer based on SQLAlchemy, instead of
> > using http://sqlobject.org/sqlapi/). This suggestion sounded very
> > rational to me, but it seems the SQLObject team-lead has not followed
> > it.

Found one:

http://www.mail-archive.com/sqlalche...@lists.sourceforge.net/msg01716.html

And one more:

http://pythonpaste.org/archives/message/20060318.172439.30ee89aa.en.html

...

> SO and SA are two different approaches to solve the same problem
>
> http://mail.python.org/pipermail/python-list/2006-September/359164.html

[...] - (some more stuff)

nice link:

"SQLAlchemy implements the Data Mapper pattern, of which the Active
Record pattern (which SQLObject implements) is a subset."

I understand this like this:

SQLAlchemy (DataMapper) can implement SQLObject (Active Record)
SQLObject (Active Record) cannot implement SQLAlchemy (DataMapper)

.

[Kevin Dangoor]

On Oct 11, 2006, at 1:50 AM, Jorge Vargas wrote:

> On 10/11/06, Ilias Lazaridis <il...@lazaridis.com> wrote:
>>
>> I was wondering how close could a SQLObject compatible API (fictional
>> name: ObjectAlchemy) placed on top of SQLAlchemy come to SQLObject.
>>
> that is not possible because they are two different design patterns

Actually, I think it is possible to have a largely compatible API
(only in one direction... SQLAlchemy can be made to be largely
compatible with SQLObject, not the other way around). Combine
ActiveMapper with some alias classes that make class declaration look
like SQLObject and you'll get quite close. Especially given that
SQLAlchemy's query syntax is largely based on that of SQLObject.

Some breakage is inevitable, but it's likely that a good portion of
an app could be migrated over.

Kevin