[PEAK] The path of model and storage

Phillip J. Eby pje at telecommunity.com
Thu Jul 29 14:32:57 EDT 2004


At 10:05 AM 7/29/04 -0700, Robert Brewer wrote:
>Phillip:
> > A mapping layer directs the transformation from abstract
> > model classes to concrete implementation classes, and
> > registers operations with the workspace's generic functions
> > to perform all necessary loading, saving, cache management, etc.
>
>I'm still rolling this one around in my head. I've encountered a great
>many ORM designers at one extreme, who feel that the DM can do all of
>that without having to create any "transformed classes"--the model is
>always 'abstract'. They tend to be those who have complete and
>monopolistic control over their data. ;) I happen to have a strong
>current use case for a more moderate position, where 2/3 of my data does
>very well with a generic DM, but the other third needs such a mapping
>layer. I took the approach of writing a bridge (wrapper) for that third
>(another process which serves domain objects over a socket). You seem to
>be taking the opposite extreme in that every (concrete) domain object
>instance has the persistence mechanism built into it...?

Depends on what you mean by "built into".  At a minimum, find() and get() 
classmethods will be injected, and there will have to be some sort of hook 
in __new__ to track creation of new instances.  There will also have to be 
intercepts of any modification to the object, and retrieval of various 
features.

(Keep in mind too that this injection will occur via simple programmatic 
subclassing of the abstract domain class.  In principle, this means you 
could define a persistence mapping for any subclassable Python type.)


> > If a mapping layer can determine everything it needs to know from
> > the model classes, it will not need a schema.  But e.g. a relational
> > database mapping layer will need a schema to configure it.  (Whereas
> > a mapping layer that reads and writes XMI files might not need any
> > data but the classes themselves.)
>
>Ah. So one possible concrete implementation class will be the abstract
>model class?

In theory, yes.  In practice, this will only be true for immutable "value" 
types like enumerations and structures, because everything else will need 
the hooks I described above.




More information about the PEAK mailing list