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,
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.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -