You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DBI->connect ($dsn, $user, $pass, $options) clearly splits the DSN and the credentials.
I'd like to see several thing "changed"
== Unification in parameter-names in the DSN ==
I have seen dbi:Xx:database=... (mysql, MariaDB), dbname=... (Pg, SQLite), db=... (Firebird), sid=... (Oracle), dbi:Xx://host:port/Foo, and f_dir=/foo (CSV) in the DSN and also plain dbi:Xx: where the database is specified in $options or environment variables (think $TWO_TASK for Oracle or $USCHEMA in Unify). Likewise for host=... vs server=.... The worst imho is an embedded DSN inside the DSN as DBD::ODBC documents: dbi:ODBC:DSN=mydsn.
The most obvious common name would be database.
== Allow User/Pass in DSN ==
Having connections stored as key-values somewhere for testing, or extending a dynamic DSN based on testing configurations would simplify testing a lot. I'd like top-level support for
my $dsn = "dbi:Xx:dbname=foo";
DBI->connect ($dsn, $user, $pass, ...);
to be equivalent with
my $dsn = "dbi:Xx:dbname=foo;user=tester;pass=secrit";
DBI->connect ($dsn, undef, undef, ...);
where the connect will extract any of user=..., dbuser=..., pass=..., dbpass=..., password=...from the DSN and put them at the spots for$userand$pass, which would default to $ENV{DBI_USER}and$ENV{DBI{PASS}`
The text was updated successfully, but these errors were encountered:
See perl5-dbi/DBD-MariaDB#147
DBI->connect ($dsn, $user, $pass, $options)
clearly splits the DSN and the credentials.I'd like to see several thing "changed"
== Unification in parameter-names in the DSN ==
I have seen
dbi:Xx:database=...
(mysql, MariaDB),dbname=...
(Pg, SQLite),db=...
(Firebird),sid=...
(Oracle),dbi:Xx://host:port/Foo
, andf_dir=/foo
(CSV) in the DSN and also plaindbi:Xx:
where the database is specified in$options
or environment variables (think$TWO_TASK
for Oracle or$USCHEMA
in Unify). Likewise forhost=...
vsserver=...
. The worst imho is an embedded DSN inside the DSN as DBD::ODBC documents:dbi:ODBC:DSN=mydsn
.The most obvious common name would be
database
.== Allow User/Pass in DSN ==
Having connections stored as key-values somewhere for testing, or extending a dynamic DSN based on testing configurations would simplify testing a lot. I'd like top-level support for
to be equivalent with
where the connect will extract any of
user=...
,dbuser=...
, pass=...,
dbpass=...,
password=...from the DSN and put them at the spots for
$userand
$pass, which would default to
$ENV{DBI_USER}and
$ENV{DBI{PASS}`The text was updated successfully, but these errors were encountered: