Interesting to know that SQLAlchemy <http://www.sqlalchemy.org> implements 
the Data Mapper pattern <http://en.wikipedia.org/wiki/Data_mapper_pattern>, 
and SQLObject <http://www.sqlobject.org> implements the Active Record 
pattern <http://en.wikipedia.org/wiki/Active_record_pattern>.

Has there been any progress of integrating the Active Record pattern into 
SQLAlchemy over the past 6 and-a-half years?

On Wednesday, October 18, 2006 5:34:10 AM UTC+11, Jonathan LaCour wrote:
>
> Ilias Lazaridis wrote:
>
> > peoples words:
> >
> > "SQLAlchemy implements the Data Mapper pattern, of which the Active
> > Record pattern (which SQLObject implements) is a subset."
> >
> > please notice: "subset".
> >
> > My conclusion is of course correct, and is based on the meaning of the
> > term "subset".
>
> The direct quote of your conclusion was this:
>
>     "SQLAlchemy (DataMapper) can implement SQLObject (Active Record)
>      SQLObject (Active Record) cannot implement SQLAlchemy (DataMapper)"
>
> Which is not "of course correct" because the statement is mixing terms
> a bit and isn't really very accurate.  Let me see if I can help you out
> a bit on those terms.
>
> Libraries cannot implement other libraries.  Libraries _can_ implement
> design patterns, though.  SQLAlchemy and SQLObject are libraries.
> Data Mapper and Active Record are design patterns.  Using this as a
> basis, here is a more correct conclusion that you could draw from
> the original statement:
>
>      SQLAlchemy roughly implements the Data Mapper design pattern.
>      SQLObject roughly implements the Active Record design pattern. The
>      Active Record design pattern can be considered a subset of the
>      Data Mapper design pattern.  As a result of this, it is possible
>      to implement the Active Record design pattern in SQLAlchemy, which
>      is provided by the ActiveMapper extension to SQLAlchemy.  It might
>      be possible for someone to implement an SQLObject compatibility
>      module for SQLAlchemy, but it might be difficult to provide 100%
>      compatibility with the SQLObject API.
>
> I hope this makes a bit more sense to you, and I again would encourage
> you to read up on design patterns a bit so that you can have a better
> understanding of the subject that you are discussing.
>
> > So, possibly "peoples words" were wrong.
>
> Please don't take this the wrong way, but you clearly aren't armed with
> the knowledge that is necessary to come to that conclusion.  The
> original quote is correct, and your interpretation of it is not.  Its
> not a big deal, but its kind of irritating when people make blanket
> statements from a position of ignorance.
>
> Also, if you don't want people to come to the conclusion that you are
> a troll, it would probably be a good idea to take the advice of the
> creator of the project, rather than ignoring it.
>
> > Sadly, I've currently not the time to further look at the persistency
> > case.
>
> Well, good luck anyhow.
>
> > Just wondering more and more about "A Dynamic Language, Without a
> > Dynamic ORM" (Python).
> >
> > Seems like Zope DB and Durus are the only dynamic solutions for
> > python.
> >
> > The ORM league has (till now) failed to produce an dynamic OO layer on
> > top of Relational databases.
>
> I am not going to comment on these statements, because I really don't
> think that they make any sense at all.
>
> Good luck -
>
> --
> Jonathan LaCour
> http://cleverdevil.org
>
 

On Wednesday, October 18, 2006 5:53:29 PM UTC+11, Ilias Lazaridis wrote:
>
> thank you for your comments.
>
> --
> http://case.lazaridis.com/wiki/Persist
>

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to