[Zope-dev] Experiments with ORMapping

[Joachim Werner]

> It sounds like you are tackling a lot of things at once.  You might
> consider dividing into separate projects.

Yep, that's what is happening right now. We are still collecting "feature
requests". Then we will sort them out. A lot of the stuff will also be
useful in different contexts than we have planned, so maybe these things
should be in a different project ...

I'm sure about one thing: "SmartObjects" will be the wron name for most of
the things we are tackling ...

> > A query like "Give me all users who have bought this and that product
and
> > are aged 20 or above" can not be handled by the catalog, I think.

> Yes it can. :-)  That's not to say that it has as much flexibility as a
> SQL query, but it can do most of the things people usually do with one
> table at a time.

I am talking about MANY tables (or object relations) ... ;-)
In the example, it's users in many different sub-folders (e.g. branded
portals), products from a product catalog, etc. If you KNOW in advance that
you will need the info, you can easily store the info pairs in the Catalog,
but if you just want to do ad-hoc data mining ...

> The CMF has a solution for this, actually.  The results of a query
> include only the things you're allowed to access.

That's why I said "standard" ;-)

> > SmartObjects is more of a programming framework than just adding
OR-Mapping
> > to Zope. So if we can solve the storage and query parts more efficiently
by
> > just having Zope itself extended a bit, this would be very cool ...

> You see, I think it is not necessary to create a programming framework
> if the goal is OR mapping.  The framework is already defined, and it's
> Python / ZODB.  But SmartObjects seems to have many loosely related
> goals, making it difficult to assist.

But "Python/ZODB" is not a high-level framework. Like Zope is not the CMF.
Nobody would implement GUIs in pure C now. They are using tools for that.
And we don't want to have to implement things like HTML forms, event
handling, etc. over and over again. We want to just configure and "compile".
Of course this will be within the Python/ZODB framework, i.e. all the
additional functionality will be "support classes" or mix-in classes like
the ones Zope already offers (e.g. CatalogAware).