[Zope-dev] Experiments with ORMapping

[Phillip J. Eby]

At 12:26 PM 5/14/01 -0400, Shane Hathaway wrote:
>Chris Withers wrote:
> >
> > Shane Hathaway wrote:
> > >
> > > One would define an "ObjectMappingSchema" whose job it is to store and
> > > retrieve objects of a specific type and in a specific location.  It
> > > would usually grab a database connection object to do its work.  When
> > > loading, it would perform a query then manually put attributes into a
> > > persistent object.  When storing, it would grab specific attributes from
> > > the persistent object and execute a statement to store those attributes.
> >
> > How does this differ from ZPatterns? Phil?
>
>ZPatterns implements storage logic on the application level.
>Applications have to be aware of (in fact they have to be centered
>around) ZPatterns.  This alternate approach keeps storage logic
>independent of application logic.  It lets you take any code written for
>the ZODB and move it to your RDBMS schema without changing the code
>(most of the time :-) ).

I am reminded of a passage from "Dirk Gently's Holistic Detective Agency", 
wherein Dirk decides to cut to the heart of the problem, and simply writes 
down the answer.  Now, he declares, he is faced with only a relatively much 
easier problem: What strange language did he write the answer down in?

While I'm not saying that what you're doing isn't possible, I *will* say 
that I believe you are replacing a small amount of API-specificity in the 
code with a similar amount of specificity, coupled with a much larger 
complexity in the mapping layers.  It is, IMHO, much harder to write 
generic mappings at the schema layer where you propose, than to do so at 
the domain logic layer where ZPatterns operates.  Ty and I spent many weeks 
chewing over designs in the space you're talking about, back before 
ZPatterns existed, after consulting at length with Jim Fulton and Michel 
Pelletier.  Our conclusion was that yes, it was *possible* to do the 
mapping you're talking about, but that it was very high impedance for the 
kinds of applications we had in mind.

I'll give a simple example to show what I'm talking about.  Consider a task 
framework where TaskPerformers are assigned Tasks, in a simple one-to-many 
relationship.  TaskPerformers, in this framework, perform up to hundreds of 
tasks per day, thousands per month.  Assuming an RDBMS backend, how do you 
propose to map this in your storage model?

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.

We haven't even addressed performance issues yet, which are the real 
killer.  The only way (again IMHO) to get reasonably high performance that 
is "portable" across different databases is to be able to write code that 
is optimized based on the back-end.  The only way you can push this code 
"under the hood" is to create an all-purpose query mechanism.  Otherwise, 
you must expose enough of the inner workings to the application developer 
that they can include "platform-specific" code for each circumstance.

All this is of course just my opinion, and quite possibly wrong.  But I 
think that an application developer would get more mileage out of your 
DBAPI product (coupled with some utility classes to replace Racks) or from 
ZPatterns than they would from this approach to O-R mapping.