Re: [Modeling-users] Re: About Database Schema Designer

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

        Hi,

> >   The most annoying problem I see is the complete lack of inheritan=
ce --
> >   there seem to be no way to model it. Okay this is quite normal fo=
r a tool
> >   dedicated to db-schema, but we'll need it somehow.
>=20
> I confirm that I saw no way to model it, it could simply become a
> specialized form of relation.

Oh, well, this should be changed, somehow, if at some point we want to =
point
to this tool for use by the framework's users.

> > - 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 propertie=
s :)
>=20
> 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 br=
idge
> and the only way I see to keep objects identity is through primary ke=
y.  I
> found the snapshot() method quite useful

Ok, I see. Have you considered using the informations enclosed within e=
very
GlobalID?

  The GlobalID of an object is its identifier within the framework ; yo=
u can
  get it from an EditingContext by using the message 'objectForGlobalID=
'.
  Every object that exists in the database is assigned a unique KeyGlob=
alID,
  whose keyValues() method returns a dictionary mapping the primary key=
's
  name with its value.

> >   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?
>=20
> To date I only used to-one but to-many can be modeled and should not
> pose any problems to convert.

Ok.

> When is Zope going to support Python 2.2 ?

I think 2.7 will officially support 2.2, but I've not checked. I've read
that 2.6 already (but not officially) supports py2.2.

> >   - defaults in mutateEntity() & mutateEntAttr() are directly defin=
ed as
> >     dictionaries, while 'mutateRelation()' uses makeDefaults()
>=20
> 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 ?
>=20
> I prefer makeDefaults()

So do I, and I'll remember that idiom for sure, really handy.

About PyDBDesigner:
> Ehhh... this tool is far from being mature...

Unfortunately, yes...

> By the way how do you achieve this funny indentation ?

Well, emacs almost does all the work! (M-q, fill-paragraph)

> > Last, just curiosity: was the zmodeler not an option for you becaus=
e of
> > zope itself or do you find/use more of the db-designer xml file tha=
t the
> > zmodeler (and/or the modeling framework's model xml file) does not
> > offer?
>=20
> 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 com=
ments
> but also the lack of visual presentation of the model.

  I'm afraid there's nothing useful to be done as far as the ZModeler a=
nd
  its lack of visual presentation are concerned. Your other remark abou=
t the
  possibility to add comments is interesting. Where would you ideally a=
dd
  these comments in the model?

        Regards,

-- S=E9bastien.