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.