Re: [Modeling-users] Roadmap to 0.9 - connectionDictionary

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

        Hi,

Mario Ruggier <ma...@ru...> writes:
> While we are making changes to the model... ;)
>=20
> - I really do not like having the connectionDictionary written out all ov=
er
> the place in xml files, some of which generated and copied around.
> Is it possible to externalize this? (Maybe I am missing something?)
> The connDict should at maximum be written on disk only once (this
> will automatically be possibly with PyModels...).

  You're right. In fact there is also a problem with PyModels: they will
  contain passwords, and be installed in the standard python path. By
  default, installation will make them world-readable, which is not good
  either.

  I suggest a env. variable poiting to a specific init-file read by
ConfigParser and changing the models' connection dictionary when they
are loaded --see tests.utils.parseConfigFile_and_updateModel() and
tests/test.cfg for an example of this technique.

  Does it sound reasonable? This can be easily done, and it will meet
  the exact requirements you're pointing out. I guess we can make it
  happen for 0.9.

> Also (a different request) passwords should not be written in the clear.
> Is it possible to send encrypted passwords to the db server?

  I've no idea -- if somebody knows what is possible w/ postgresql and
  mysql, please tell. Otherwise we'll have to search the official
  docs. I suggest for we forget this for 0.9, though. Could you fill in
  a RFE?

> - Another minor request, that can wait; would it be possible to make
> entity/@name the default for both entity/@className and entity/@externalN=
ame,
> should these two not be specified in the XML model?

  It's not difficult at all (it's already done in the ZModeler). Now I
wonder whether it is a good idea to change a model while loading it at
runtime. Dunno why, but this hurts me a little for xml files, however it
seems to make sense for the coming pymodels... Oh well, I'm confused
now, let's think a little more about it.

  BTW: the default for entity/@className would preferably be
       Entity.externalNameForInternalName(entity/@name)


        Cheers,

-- S=E9bastien.