[PEAK] A ridiculously simple mapping layer
Phillip J. Eby
pje at telecommunity.com
Wed Jul 28 11:12:35 EDT 2004
At 10:12 AM 7/28/04 +0200, RochÃ© Compaan wrote:
>Phillip J. Eby wrote:
>>Duh. D'oh! So simple, yet 100% modular and reusible/extensible. We
>>define our domain model as a module, or set of modules. We define a
>>physical schema as a class. Descriptors on the schema map from the
>>"pure" domain class to an implementation-specific subclass. That is, in
>>the example above, 'ws.Customer' and 'ws.Invoice' do not return either
>>the original class in 'mymodel', but rather a *subclass*, that knows it
>>is part of that workspace.
>Since you're onto the implementation details in a subsequent post I can
>now ask a question about the implementation that I don't see clearly.
>Specifically, where do I define the *subclass* and where will the
>descriptor look for it? Or must I code the descriptor?
The mapping objects (e.g. 'mapTable') *are* the descriptors, and they
generate the subclass automatically.
>>The subclass is just the original class plus:
>> 1) a mixin (e.g. 'RelationalMixin', 'LDAPMixin', etc.) that defines
>> the mapping process
>> 2) some metadata to drive the mapping (table name, field names,
>> 3) classmethods such as 'find', 'get', and 'delete'
>> 4) overrides of domain-specific instance or class methods where
>> necessary for performance or to handle unusual mapping requirements
>If you show 'RelationalMixin' in a class definition and how that
>*subclass* is used, I'm sure I'll understand where you're going.
The subclass will be automatically generated. You'll never see it in code,
as it'll be created using something like
More information about the PEAK