Re: [Modeling-users] Pythonic, and non-XML, Model description
Status: Abandoned
Brought to you by:
sbigaret
|
From: Mario R. <ma...@ru...> - 2003-05-19 09:52:50
|
hi,
On dimanche, mai 18, 2003, at 18:25 Europe/Amsterdam, Sebastien Bigaret
wrote:
> Hi,
>
> A little more on the current choices and implementation for PyModels.
>
>> Association('E1', 'E2',
>> multiplicity = [ [0,1], [0,None] ], # optional or
>> mandatory?
>> relations = [ 'toE2', 'toE1s' ], # optional
>> keys = [ 'fkE2', 'id' ], # optional
>> delete = [ 'nullify', 'nullify' ], # optional
>> isClassProperty = [ 1, 1 ], # optional
>> joinSemantic = [ 0, 0 ], # optional
>> displayLabel = [ '', '' ], # optional
>> doc= ['to one', 'to many' ], # optional
>> )
>
> Branch brch-0_9pre7-1-PyModel now fully implements this API for
> associations. The multiplicity is *optional*, this means that:
>
>> Another thing I must stress is that Association currently associates
>> E1 --> E2, w/ E1:toOne-->E2 and E2:toMany-->E1
>
> is still correct.
OK with this.
>> [About modeling the StoreEmployees model]
> Mario> > Nice. Version with Associations and no Relationships?
>
> The StoreEmployees model is also fully implemented with Associations
> only and can be found at
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/modeling/
> ProjectModeling/Modeling/tests/testPackages/StoreEmployees/Attic/
> pymodel_StoreEmployees.py?rev=1.1.2.2&only_with_tag=brch-0_9pre7-1-
> PyModel&content-type=text/vnd.viewcvs-markup
I like the Association idea -- it makes the model more clear and
concise.
However, I feel there could be some confusion generated with the
interplay of Associations and Relationships, particularly in how
defaults
are determined. In the implementation, associations use defaults from
the appropriate Relationship class. Does this mean that when using
Association one has to set defaults on Relationships, or can one simply
set the defaults on Association? (Also in the sample PyModel some of
the rel defaults are not needed.). Namely, would we be able to replace
the R defaults:
RToOne.defaults['delete'] = 'nullify'
RToOne.defaults['multiplicity'] = [0,1]
#RToOne.defaults['sourceAttribute'] = RToOne.attNameFromRel #
'fk'+destEnt+destAtt+count
#RToOne.defaults['destinationAttribute'] = 'id'
RToMany.defaults['delete'] = 'cascade'
RToMany.defaults['multiplicity'] = [0,None]
#RToMany.defaults['sourceAttribute'] = 'id'
#RToMany.defaults['destinationAttribute'] = RToMany.attNameFromRel #
fk+destEnt+sourceAtt+count
simply with:
Association.defaults['delete'] = ['nullify', 'cascade']
(For multiplicity, srcAtt, dstAtt, these are already the "stock"
defaults, so we do
not need to restate them, except if we just want to make things
explicit.)
Is there a difference in doing this? The fact that Assocs use defaults
from Rels,
but that Rels do not use defaults from Assocs should not be a problem --
the idea to use Assocs is to simplify how to state Rels, and in the
same model it would be better not to require that stuff is set on Rels
to use Associations?
BTW, you said earlier that you want to keep RToOne/RToMany
classes, to stay compatible with the current XML model -- this is a
good thing of course. But, when this design settles down, would adding
the Association construct to the XML model not be appropriate?
Will PyModels interact with the 4 utility scripts (mdl_compile_model.py,
mdl_generate_DB_schema.py, mdl_generate_python_code.py,
mdl_validate_model.py) in the same way as XML models?
>
> It passes the framework's tests (cf.
> test_Editing_Global_Inheritance).
>
> Last (off-topic but it will be integrated in the next release): I
> changed the way delete rules are stored for relationships: instead of
> integers, they are now stored as plain strings ('nullify', 'deny',
> 'cascade'): this makes things clearer. Of course, you can count on
> backward compatibility and your (xml)models storing the delete rules as
> integers are still loadable.
OK, to be updated in the user guide.
mario
|