Richard Nuttall wrote: >> - support for automatically pulling database DSN information from a >> ~/.dbi (or similar) file. This is constantly re-invented poorly. >> Let's just do a connect by logical application name and let the >> SysAdmins sort out which DB that connects to, in a standard way. > This reminds me one one thing I hate about DB access, and that is having > the DB password > stored in plain text. Sadly, there is really nothing that can be done about this, other than "casual" obscuring of the real password like CVS does in ~/.cvspass However, making it in a file in $HOME/.xxx means that the sysadmin can set it up to be mode 400 or something like that, to ensure other users can't access it if someone forgot to set the permissions right on the application code (or, hopefully, configuration file). Of course, for more secure access schemes like kerberos, etc, the file is really just being a little registry of available data sources. On a similar note could be allowing overriding the data source used by an application by setting an environment variable. That way, the SysAdmin has got lots of options when it comes to managing different production levels - Oracle has this with TWO_TASK, and while it's a PITA when it's not there (no doubt why DBD::Oracle allows this to be specified in the DSN string), it's also useful for what it's intended for - switching databases from an operational perspective. Sam.Thread Previous | Thread Next