On 14/01/2011 10:21 AM, Martin J. Evans wrote:
On 14/01/11 15:01, H.Merijn Brand wrote:
On Fri, 14 Jan 2011 14:56:46 +0000, "Martin J. Evans"
<martin.ev...@easysoft.com> wrote:
On 14/01/11 14:30, H.Merijn Brand wrote:
Maybe this is a feature request, but if I have
ORACLE_USERID=john/sekrit
DBI_USER=pablo
DBI_PASS=neruda
I *do* expect that DBD::Oracle uses DBI_USER and DBI_PASS *instead of*
the ORACLE_USERID. Anyone can come up with a good reason why this os
not happening at the moment?
How do other DBD's set precedence if environment variable are allowed
for login credentials?
Just a minor point (not saying it stops the discussion) but I don't
think ORACLE_USERID is something DBD::Oracle defines (other than in
test code in t/*). So is your point to do with running tests in t/* or
in general?
I ran into this in the test suite indeed. Your findings below just
confirm my expectation :)
I posted it here because I saw no generic docs about this
It is in the README.
The supplied tests will connect to the database using the value of the
ORACLE_USERID environment variable to supply the username/password.
Don't know why it cannot fall back on DBI_USER/DBI_PASS.
$ export ORACLE_USERID=wrong/wrong
$ export DBI_USER=real_user
$ export DBI_PASS=valid_password
$ export DBI_DSN='dbi:Oracle:host=betoracle.easysoft.local;sid=devel'
$ perl -le 'use DBI; my $h = DBI->connect();'
works for me. i.e., ORACLE_USERID contains invalid username/password
and DBI_USER/DBI_PASS contain valid username/password and it connects
fine.
Perhaps I misunderstood you Merijn.
Martin
Martin
Why not.
Seems like a good Idea and easy to implement I guess we are just
carrying on an old tradition nothing says we have to use ORACLE_USERID
which is a little out dated.
Time to update the POD and a tests I guess.
Might be best for 1.29 as 1.28 is rather full right now.
Cheers
John
