[Modeling-users] Re: About Database Schema Designer

[Yannick G. <ygi...@yg...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 27 February 2003 19:50, Sebastien Bigaret wrote:
> - about the tool itself: it is really focused on db-schemas ; it has some
>   features I cannot understand, such as the 'type' of a relation
>   (identifying, identifying or informational), or the referential integrity
>   properties for the child/destinationEntity (insert/update props). May be
>   you can comment on these?

Referential Integrity: cascade the delete with references on foreign
                       keys, don't allow inserts with a non-existing
                       foreign key.  Or something close to that...

I simply ignore those informations in the conversion for now.

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

I confirm that I saw no way to model it, it could simply become a
specialized form of relation.

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

We could load customs defaults from a .dd2pmrc or allow a command line
argument.  As I said in a former email, we need to cross a XML-RPC
bridge and the only way I see to keep objects identity is through
primary key.  I found the snapshot() method quite useful

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

To date I only used to-one but to-many can be modeled and should not
pose any problems to convert.

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

I can't...

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

No Problem.

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

No Problem either.

When is Zope going to support Python 2.2 ?

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

I got tired of quoting dict keys so I used a quick hack I saw in the
Python Cookbook.  I agree that we should use only one way to do it all
across the script, which one do you find cleaner ?

I prefer makeDefaults()

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

There are some part of the interface that are a bit annoying.  You
can't edit an attribute by double-clicking on it from the entity-tree
and minor stuff like that.  A really nice feature is that you can put
remarks everywhere.

>
>   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 definitely
>   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
> their 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.

Ehhh... this tool is far from being mature...

By the way how do you achieve this funny indentation ?

> 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
> zmodeler (and/or the modeling framework's model xml file) does not offer?

Zope was not a problem since we already had a Zope up and running but
I'm not sure if we would have installed one just to test the
framework.  The main problem with the ZModeler is the lack of support
for various comments but also the lack of visual presentation of the
model.

We tried data-designer and it happened to be really easy to import the
schema into a model, easier that fixing the ZModeler so we opted for
an external editor.

- --
Yannick Gingras
Byte Gardener, Savoir-faire Linux inc.
(514) 276-5468
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+YMterhy5Fqn/MRARAvNEAJ9OhsDDVR0J9k87S3iSCyfJzuECUwCfYaRD
mjgxDd0aH3KMZr/XAuv1shQ=
=iW8w
-----END PGP SIGNATURE-----