[PEAK] peak.model and mappings?

[Bob Ippolito]

On Feb 23, 2004, at 8:12 AM, Phillip J. Eby wrote:

> At 08:35 PM 2/22/04 -0500, Bob Ippolito wrote:
>> How are you supposed to define a mapping with peak.model?  I'm 
>> looking for something that would be used like this, in theory:
>>
>> from peak.api import *
>>
>> class MyElement(model.Element):
>>
>>     class elementToStringMapping(model.Mapping):
>>         referencedKeyType = 'MyElement'
>>         referencedType = model.String
>
> There isn't such a feature type at present, I'm afraid.  But if you 
> look at peak.metamodels.MOF131.Namespace, you'll see an implementation 
> of an "indexed" relationship whereby a sequence of objects is also 
> indexed in a mapping.  It's not quite the same thing, but for some 
> applications it's actually better, since it also retains sequence 
> information.  If your value objects don't reference their keys, use a 
> tuple as the target type.  IOW, if your feature's singular name is 
> 'mapping':
>
> anElement.addMapping((key,value))
>
> would add the key-value pair.  You can define additional verbs of 
> course that do this in a cleaner-seeming way, according to your app's 
> needs.
>
> Or you can completely override the standard stuff and do it your own 
> way altogether.

Ah I see.  Basically, what I was trying to do was more of a metamodel, 
like building tables in SQL (not triggers, stored procedures, etc).. 
model the data, not its behavior, so I wanted to put as much metadata 
in there as possible.  I think I will try and develop my own 
"model.Mapping" to go along with this style, because I don't want to 
tie myself to python dicts, or ZODB BTrees, or what have you, and I do 
need to know what kind of objects are used for keys, and what for 
values.

Basically, I want to define the specification and decide what the 
implementation is going to be later, or even use the specs to implement 
a storage for me (i.e. design SQL tables based upon my Element classes 
and their StructuralFeatures).

-bob