[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, 
>> converters)
>>   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 mailing list