Web tool kit : pro - cons ?

[Ian Bicking]

On Wed, 2003-07-30 at 11:00, Jeffrey P Shell wrote:
> >> Other tools try the O-R
> >> mapping route for abstraction with varying degrees of success.
> >> SkunkWeb has PyDO, Webware has one (I can't remember its name right
> >> now).  Zope's model is nice because it's not intrinsic to Zope that
> >> you use SQL - it's just a nice model to plug into if you need it, when
> >> you need it.  I don't know how other toolkits stack up here.  Some may
> >> just say "go find a Python adapter that works for you and do what you
> >> want with it", which seems to be as good of a way to go as any.
> >
> > PyDO and MiddleKit (Webware's) are both independent of their frameworks
> > (it's kind of unfortunate that they appear to be tied, though), as are
> > the other ORMs (like my SQLObject).  All three provide something
> > approximating business objects built around database rows.
> 
> They all put the model too close to the Python code for my personal 
> comfort.  Sometimes that's good.  Other times, not so much.
> 
> A couple of more interesting systems are Modeling ( 
> http://modeling.sf.net/ ) and Ape ( 
> http://hathaway.freezope.org/Software/Ape ).

I don't really see the advantage of Modeling -- it seems terribly
verbose to me, though I suppose that's because of its origins in
Objective C.  I don't see any advantage to separating the mapping from
the class -- it's all code, it's all written by the same people, and if
you need separate people to handle the pieces and you can't let them
both work with the same class, either you don't have enough
communication between people or you are making the whole thing a lot
more difficult than it should be.  Modeling feels too formal to me --
more like Java than Python.  A Python ORM doesn't have to be hard.

APE seems like the other side of formal, where it tries too hard to
seamlessly support every Python object and in the process is just
another object database (ala ZODB) that happens to be able to use a
relational database as a backend.

A relational database cannot hold arbitrary Python objects unless you
want to ruin everything that's good about a relational database.  What
notions of inheritance that can be implemented have significantly
different semantics than Python inheritance (and composition is usually
better than inheritance anyway, and that is well supported by relational
databases).  Attributes aren't columns, Python types aren't database
types.  Relations are a different environment all around.  I personally
can't see the use case where you'll want to radically change storage
mechanisms while leaving a business class alone.  Yes, you may want to
radically change the storage -- but it only matters that the *interface*
to that class can stay the same, not that the entire class
implementation is storage-neutral.  That it requires some effort and
thought to move from an RDBMS to a flat file (for instance) is not a big
problem in my mind.  Moving from, say, Postgres to MySQL without effort
*is* nice, and achievable without having separate mapping objects.  I
think if APE is going to be relational, it has to be more like an ORM.

And, for what it's worth, SQLObject does have a DBM-based backend (which
is largely equivalent to a flat file backend), that is fully functional,
including selects and joins.  It's not that efficient -- but it could
be.  But having written that storage mechanism, I still think it's
little more than a parlor trick, a clever abstraction that appeals to a
programmer but offers little real benefit.  The DBM backend is just an
embedded relational database, and SQLite is a much better embedded
relational database, so you might as well use that.  If it shows
anything, it is that the queries that SQLObject uses are portable beyond
SQL, should you ever need to do that.

  Ian