Re: [Modeling-users] Pythonic, and non-XML, Model description

[Sebastien B. <sbi...@us...>]

        Hi,

Mario Ruggier <ma...@ru...> wrote:
[snip]
> 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:
>=20
> RToOne.defaults['delete'] =3D 'nullify'
> RToOne.defaults['multiplicity'] =3D [0,1]
> #RToOne.defaults['sourceAttribute'] =3D RToOne.attNameFromRel #
> 'fk'+destEnt+destAtt+count
> #RToOne.defaults['destinationAttribute'] =3D 'id'
>=20
> RToMany.defaults['delete'] =3D 'cascade'
> RToMany.defaults['multiplicity'] =3D [0,None]
> #RToMany.defaults['sourceAttribute'] =3D 'id'
> #RToMany.defaults['destinationAttribute'] =3D RToMany.attNameFromRel #
> fk+destEnt+sourceAtt+count
>=20
> simply with:
>=20
> Association.defaults['delete'] =3D ['nullify', 'cascade']

  You're right in a certain way: by construction Associations take their
  defaults from RToOne and RToMany. BUT: this is done when the module
  Modeling.PyModel is instanciated, hence any defaults set on RToOne and
  RToMany within the pymodel itself *do not influence* the way
  Associations are built.

I understand this is confusing (only if you read the code, though ;)
Maybe I'll remove the way Associations' defaults are set in the code,
this would help clarify the way... they do not interact!

  For the sake of clarity: in the pymodel for StoreEmployees I posted,
RToOne and RToMany defaults have *no* impact at all on the way relations
beneath associations are built. They should be removed (done on CVS) and
replaced by Association.defaults just as you said.

> Is there a difference in doing this? The fact that Assocs use defaults  f=
rom
> 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?

  Sure.

  About interdependencies: I do not think that defaults which are in
    common should be propagated between Rels and Associations. And I do
    not really want it either: they should be considered different.

Yet another precision even when I'm sure you meant it right :)
> 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.=20

  It's more than compatibility w/ the xml model: we need to be able to
  express any configurations supported by the framework. For example:

    - an Association won't let you specify that a FK should be a class
      property, unles you explicitly declare the AForeignKey,

    - you cannot design an uni-directional association
      Entity_1-->Entity_2 (with no inverse) with a PyModel.Association,
      here you need RToOne or RToMany to do the job.

> But, when this design settles down, would adding
> the Association construct to the XML model not be appropriate?

  I would say no, just because I consider the xml file to be the *exact*
  representation for a E-R model. It has no defaults, every single
  property is listed along with its value. XML files are the way models
  persists.
    BTW you might have noticed that I added a special property 'version'
  on PyModel; this is mainly because PyModels can heavily depend on the
  defaults. These defaults could be changed from time to time and when
  this happens we really want the user to know about this so that he can
  review the changes and adapt the PyModel if needed.

  Back on integrating Associations in xml models: I can see two more
  reasons why /I/ think this is probably not a good idea:

    - Associations depends on more defaults than other, e.g. in
      the way keys (source and destination attributes for relationships)
      are generated when they are unspecified.

    - There is no Association in the modeling layer (model, entity,
      attribute, relationship and join). This is intended and considered
      out of the scope of the E-R model; quoted from the TODO list:

      | a real (UML) Association class is needed -- Relationships (and
      | Joins) can be instanciated from them, and this would make it
      | possible to have a real object model and an 'physical' model. To
      | be continued.
      |
      | More generally this would be a good idea to have a real UML
      | model, being mapped on a E-R model for the physical (DB)
      | layer. Well, this is in fact outside the scope of the framework,
      | which will always need a model as it is (i.e. a description on
      | how to cross the bridge between the OO-world and the
      | Relational-world), but this would be a real enhancement in the
      | way the models are designed.

This also suggests another remark: while PyModels offer a lot of
facilities to quickly design models (in fact, they offer the same than
the ZModeler already does), I would not recommend deploying a
application with a pymodel using Association or any other implicit
declaration of attributes (such as automatic FK creation, applying
defaults, etc.):

  - most properties influences the framework at runtime. I did my best
    to make the PyModel's implicit mechanisms predictable, but I wont
    rely on this for a production environment, definitely (or we'll need
    to proove the predictability and this is too much work)

  - ''explicit is better than implicit'' ;)

When pymodels are integrated in the framework's core I plan to change
the python-code generation so that it also drops in the generated
package a pymodel (derived from a pymodel or directly from an xml file)
expressing all properties explicitly (this would make it an exact
equivalent for the xml file). I say that because of the reasons stated
above, plus because I also suggest that pymodels become the default for
loading models (they are much, much faster than parsing xml).

  Note: xml files are used by some people (e.g. Yannick said here that
        he generates them from the xml produced by another tool). I'd
        like to restate here that xml models won't be deprecated.

> 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?

  Absolutely, even if it's not done yet --but that's the easy part!


-- S=E9bastien.