[Zope-dev] Experiments with ORMapping

[Joachim Werner]

> My thought on this, is that you will be forced to explicitly consider the
> nature of this relationship and its storage at the application level.  If
> you write explicitly for ZODB, you might use a BTree, for example.  Or
> perhaps you'd have some kind of global container for the Tasks, with a
> Catalog to index them, and a method on TaskPerformer to query the Catalog.
>
> How would you propose to map this to an RDMS?  Well, substituting catalog
> queries might be relatively straightforward, but perhaps rather time
> consuming to develop in a generic way.  The BTree might give you a bit
more
> trouble.  Probably you'd have to end up using some sort of generic
> queryable containers that translated to BTrees or Catalogs or RDBMS
tables,
> depending...
>
> And lo!  You now have an application framework.  Oops.

I'll try to somehow get your and Shane's opinions together a bit: I think
Shane's approach does most of the job (of OR mapping) if the objects we are
talking about are relatively simple and the application domain is relatively
typical for what Zope can do well. E.g. the composite objects we have in
mind for the groupware (user credentials coming from LDAP, rest in the ZODB,
or file stored in the filesystem metadata in SQL DB, rest in ZODB) can
easily be modelled this way. And the existing Zope API (manage_AddX,
manage_changeProperties etc.) would do most of the job.

But the problems start with querying. Can the ZCatalog do it? Does it make
sense to implement a "SQLZCatalog" instead of just offering native SQL query
objects or an abstract query language like SkinSkript? To put it simply: The
reason why we want to develop a "framework" (or framework extension) is that
the Zope framework just doesn't do the stuff we need yet. BTW, the reason
why we didn't just use ZPatterns was very similar: ZPatterns makes it easy
to write an abstract implementation of a project, but you still have to
write all the "glue code" between the storage and the application layer by
hand. What we want (and what TransWarp is about, with a slightly different
focus) is that we can just map an attribute to a data source and all the
glue code (either ZODB or SQL statements) is auto-generated.

If the new "framework" just extends the existing Zope API, I don't see a
problem. ZPatterns did not, but maybe it is just not that easy to do so (and
not all parts of the Zope API really should bear this name ...).

The really good thing about the whole discussion is that at the end we will
see much better where we should put things. We (the SmartObjects people at
iuveno) do not really want to have a completely new world of SmartObjects
that will require a new API to learn. We just want to add new functionality
to Zope, be it in the core or as mix-in classes, or through-the-web
products.

Joachim