About Database Schema Designer [was: Re: [Modeling-users] Pythonic, and non-XML, Model description]

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

        Hi Yannick,

  Thanks for the script. I've not played a lot with db designer, but re=
ad
  your code with a db-designer model at hand and converted a simple
  model. That inspired me the following comments:

- about the tool itself: it is really focused on db-schemas ; it has so=
me
  features I cannot understand, such as the 'type' of a relation
  (identifying, identifying or informational), or the referential integ=
rity
  properties for the child/destinationEntity (insert/update props). May=
 be
  you can comment on these?

  The most annoying problem I see is the complete lack of inheritance --
  there seem to be no way to model it. Okay this is quite normal for a =
tool
  dedicated to db-schema, but we'll need it somehow.

- about the script: yes, there are some default values, but they are ea=
sily
  identified hence this is not really a problem changing these (I notic=
ed
  you really want to have your primary key as class properties :)

  I was really surprised by the way relations are mapped to
  relationships. If I'm not wrong, you're mapping them to 'to-one'
  relationship, unconditionally. However, when I tried the tool, I came=
 to
  the opposite opinion, because of the 2nd screenshot:
  http://www.danny.cz/screenshots/datadesigner1.jpg

  Given that "firmy" has an attribute "forma_id" which is also the PK of
  entity "forma" and that the former entity has a relation to the latte=
r, my
  first conclusion was that the relations were intended to model to-many
  relationships... But czech is greek to me ;) so this is nothing more =
than
  an intuition.

  Can you explain your practices wrt the relations? Do you design to
  relations, one being the inverse of the other, when you design a model
  with the db-designer, and edit the xml file afterwards to change one =
of
  these from to-one to to-many?

- Unused stuff in relations' props that might be used when mapping a mo=
del:

    - Parent (source entity) & Child (destination entity) props:
       mandatory/non-mandatory: this can be used to set the lower
       multiplicity bound to 1 or 0, respectively.

    - In 'Referential Integrity': it seems that parent's delete policies
      'none', 'restrict', 'cascade' & 'set NULL' maps to DELETE_NOACTIO=
N,
      DELETE_DENY, DELETE_CASCADE and DELETE_NULLIFY, respectively.

      I do not fully understand what are for: parent's update policy, as
      well as child's insert & update policy. If someone could bring in=
 a
      light...


- misc.:

  - on db-designer 0.4, there's a 'default' for attribute that can be u=
sed
    for defaultValue --to be added to mutateEntAttrType(). 'int' and
    'integer' expected by the scripts seem to have disappeared and repl=
aced
    by int2, int4 and int8 (same for float -> float4 & float8) -- to be
    updated in DD_PM_TYPE_MAP

  - 'class ModelingDDImporter:' simply not making it derive from 'objec=
t'
    makes the script available for py2.1 as well.

  - defaults in mutateEntity() & mutateEntAttr() are directly defined as
    dictionaries, while 'mutateRelation()' uses makeDefaults()


Any comments from your experience will be helpful to fully appreciate t=
he
db-designer. Some features could be added easily (such as a checkbox for
isClassProperty in attributes and relations), other would be more diffi=
cult
(such as a support for inheritance). Are you by any chance in contact w=
ith
the maintainers?


  Another tool that may be useful is PyDBDesigner at
  http://pydbdesigner.sourceforge.net/   (thank you Soaf for the link)

  It's python-based, only at an alpha stage for the moment but definite=
ly
  worth a try. I currently do not have any time to study both of these =
tools
  in details but if anyone feels like doing it I'll be interested in th=
eir
  comments. Having a stand-alone modeler (i.e. out of zope) is a real
  concern as far as I'm concerned and since time is a concern as well |=
: I
  would for sure prefer using or may be forking an existing project, if
  possible, rather than coding it from scratch.

Last, just curiosity: was the zmodeler not an option for you because of=
 zope
itself or do you find/use more of the db-designer xml file that the zmo=
deler
(and/or the modeling framework's model xml file) does not offer?

           Cheers,

-- S=E9bastien.


Yannick Gingras <yan...@sa...> wrote:
> On Wednesday 26 February 2003 03:28 pm, Sebastien Bigaret wrote:
> > Would you mind sharing your conversion scripts from db-designer to
> > xml-modeling? I'm thinking of adding a few notes on this tool in the
> > framework's documentation, and having the conversion script would be
> > really handy.
>=20
> The script is really sketchy at the moment with a lot of default
> values hard-coded but it would not be hard to modularize it enough to
> make it useful for the general public.
>=20
> I let you look at it, tell me how we could make it more general and
> I'll see what we can do.
>=20
> Fell free to ask questions about the implementation.
>=20
> --=20
> Yannick Gingras
> Byte Gardener, Savoir-faire Linux inc.
> (514) 276-5468