[Zope-DB] Change connection objects outside of Zope

[Matthew T. Kromer]

Dario Lopez-Kästen wrote:

>----- Original Message -----
>From: "Mark Langkau" <mlangkau@execpc.com>
>
>>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
>
>http://www.zope.org/Members/shai/ZForwardingDA
>
>has anyone used it and can share any experinces?
>
>/dario
>
>oh... Thank you for the new list !!! :-)
>
;)


[This really ought to go on Zope-dev, since it doesnt relate to DBs 
specifically but...]

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

etc...

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

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.