[Zope-DB] Change connection objects outside of Zope
Matthew T. Kromer
Thu, 16 Aug 2001 14:31:54 -0400
Dario Lopez-Kästen wrote:
>----- Original Message -----
>From: "Mark Langkau" <firstname.lastname@example.org>
>>How would I go about programmatically changing the connect string in a
>>database connection object? In our production environment, we change our
>>database passwords on a regular basis. It will become a pain to change
>>all of the hard coded user/password strings in the connection objects.
>>(There may not be a large number to change - but *remembering* to change
>>them, and to find all of them will become a maintenance issue ;-)
>hm... this might be solvable by using the Z Forwarding Database Adapter
>has anyone used it and can share any experinces?
>oh... Thank you for the new list !!! :-)
[This really ought to go on Zope-dev, since it doesnt relate to DBs
One of the notions I've considered in the past is how Zope stores
configuration data; right now, there's little fiddly bits all over the
place that are activated/deactivated by various mechanisms, from
environment variables to file system probing, etc.
I tend to like the Netscape/Mozilla "prefs.js" -ish approach, being that
you have in some location a highly specialized 'configuration store'
which has all the tunes & knobs and so on in one place. Ideally, the
file should be easily editble with a text editor, so that leads me to
like formats as follows:
compound.variable = value
compound.variable = value
The notion is about the same as the Windows registry, etc. If, for
example one established a configuration line like
da.dco2.connectionString.mydb = "scott/tiger"
the adapter might be configured such to acquire that value, perhaps with
the leading prefix being known in advance, e.g. you'd only have to tie
the name "mydb" to the connection object, and "mydb" might implicitly be
the ID (name) of the connection object.
This does NOT address security concerns -- which would probably
complicate matters. If each configuration item required special
security on it to prevent accidental disclosure and/or modification, one
would probably have to envision a system of directives specifying each
branch of the configuration tree and the relevant keys, algorithms, and
other identifiers for a run-time system to be able to use them. For
example, it might require passing a password to Zope on startup so that
it can use that to unlock 'secured' configuration items. And then
there's the zope-ish scripting security concerns like "can I see your
configuration data when I shouldn't" which tend to make me Not Want To
There are various internal policy decisions why Zope has no such
facility at this time, but this does not mean a discussion about
implementing such a control store is off-limits.