Re: [Modeling-users] Foreign key required for 1:1 relations Schema update thru differences

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

        Hi Erny and all,

"Ernesto Revilla" <er...@si...> wrote:
> I started modeling with the ZModelingTool and the following issues arose:
>=20
> * When I modeled
>             1                                    0..*
>          addresses                         person
> Person <---------------------------->>address
>=20
> although I told in the relation in entity address that it had to map '1:1'
> to Person, it didn't set the FK_Person to required. During model validati=
on
> I got the warning :
> - relationship is mandatory  but source attribute direccion.FK_PERSONA is
> not required.
>
> All in all, I see the tool a bit redundant, because:
> * the former issue should be done automatically

I guess you declared the FK, than the relationship, and then set the
relationship's multiplicity to 1..1.

Note: If you had used the 'Add relationship' stuff on the model's
      properties page, the FK would have been created and set to
      required, as expected.

That's completely normal --and that's why the validation is here. I
understand you have the feeling that this is redundant, but in fact it's
not (even if most of the time it is). The idea here is that it's just a
warning, moreover it's sometimes exactly what you want: for example, you
do not want the generated DB schema to include the 'NOT NULL' stuff for
a given field if you know you'll populate this with existing data that
are not fully correct (so we don't want to change the FK property
automatically).

The best way of handling this would be to check the FK's properties when
a relationship's multiplicity changes ; then ask the user if he wants to
update it as well. But you must understand that if we're going that way,
then I think there are a lot of such warnings/suggestions to users to
issue at almost each possible changes. This would complicate the tool a
lot, and I have the feeling that a web interface is not really
appropriate for this.

  Here's the philosophy currently underlying the ZModeler: design your
  model, check the model, correct it when applicable, iterate ;)

> * I would like to map all python string to varchar (w/o limit) or text (in
> fact, they should all be mapped to the same (perhaps system dependent) DB
> type

Right, the ZModeler does not handle this for the moment being. See below
the discussion on PyModels.

> * typeName is required but not used

It's not required, it's just an 'info' message. But okay, since it's not
used for the moment being it might be dropped (and from the interface as
well). For the curious, this field originally came from a previous
version of the framework (never publicly released), where it was based
on ZODB+ZCatalog (no rdbms at all), and the field was used to generate
python and/or cmf zproducts.

> * name, className, moduleName and externalName have all to be specified,
> perhaps the latter three should be defaulted to the first if not specifie=
d.

When you create a class within the tool, they are automatically
specified, ain't they?

> Sorry, this should not sound too destructive. I really appreciate a lot a=
ll
> the work done. I just think that the XML-file is too explicit (with all t=
he
> required fields). Perhaps the semantics could be loosened a bit, making al
> lot of the attributes optional (like moduleName, packageName, externalTyp=
e,
> etc.)

No need to worry. We really need to know what annoys new users --most of
us here are far too accustomed to the way it reacts to be able to detect
those things.

About the XML file: yes, it is very explicit indeed. That's why the
ZModelizationTool was built anyway, because it's almost impossible to
build a xml-model from scratch.

  You already pointed that out: even the defaults (applied when a field
  is not present in the xml file) are not clearly stated. The fact is
  that the xml model should be thought as a complete snapshot for a
  model (serialization of a model). This sounds reasonable, but I must
  admit that the very reason for this situation is that the classes
  Model, Entity, Attribute and Relationship were the starting point of
  the project; if you look at their code, you'll probably notice that
  they are messier than others' --they need refactoring, but it's never
  been done since the beginning (they lived through two major rewrite of
  the framework before the current one), they've just grown from what
  they were to what they are and obviously they lack clear support for
  things like clear definition of defaults.

Now that applications are deployed, it's complicated to change this,
just because some people are using the 'observed' defaults which should
not be changed from one version to another. Say it differently:
refactoring these classes requires an exhaustive review of every single
defaulting behaviour. And that's not a high-priority item... (same for
the ZModelizationTool however, whose code I'm pretty ashamed of, <g>,
ugly one)

  Have you looked at the PyModel proposal (implementation has begun and
will probably be integrated into the main trunk in a near future) ??

The original post by Mario is at:
https://sourceforge.net/mailarchive/forum.php?thread_id=3D1702463&forum_id=
=3D10674
then the full thread is at:
https://sourceforge.net/mailarchive/forum.php?thread_id=3D1703927&forum_id=
=3D10674
and
https://sourceforge.net/mailarchive/forum.php?thread_id=3D1755270&forum_id=
=3D10674

(sorry about the thread being splitted in three parts in the archives,
 my fault: my mailer was not correctly configured at that time--I can
 digest and send the whole stuff to you if you wish)

--> the PyModels design was initiated because of the lack of readability
    and clarity of the xml model. They contains exactly what you're
    looking for: defaults (so you can tell that every string attribute
    are TEXT), and a wide range of verbosity, allowing you to declare
    the minimal amount of required stuff up to the whole set of possible
    properties).

If you want to give a try, you can get the cvs branch tagged
'brch-0_9pre7-1-PyModel'

> If I can help, please tell me how. (I think I really need this project for
> our own (ERP).)

Reporting all these things already helps. If you feel like patching the
ZModeler for the FK problem you reported, go for it! Or you can simply
gather all annoyances you notice using the ZModeler and then submit a
feature request. I have the feeling that after the PyModel are released,
they could benefit a lot to the Ztool.

  Do not misunderstand my answers in general: I always try to make it
  explicit why things are like this or that, even when there's nothing
  to be proud of :/  When I say that sth is on the TODO list but
  low-priority, I basically mean that I already have too much to do with
  high-priority items, so *I* probably won't have the time to
  concentrate on low-priority items. Obviously, I'll always be happy to
  help anybody willing to change/enhance things.  Collaborations can
  take various forms (up to transfer of responsability for a given
  module, say, the ZModeler:), and as a general rule discussing these
  things generally tends to augment their priority level.

Again, thanks for reporting, and keep it up, we need fresh eyes!

        Cheers,

-- S=E9bastien.