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 |