[PEAK] A ridiculously simple mapping layer

[Phillip J. Eby]

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 
'base.__class__(name,(base,RelationalMixin),dict)'.