Re: DBIx::DBH - Perl extension for simplifying database connections
On 2004-12-07 22:36:58 -0800, Jonathan Leffler wrote: ConnectionStrings.com - Forgot that connection string? You will ... www.connectionstrings.com - All connection strings in one place! Here you'll find the syntax for ... It seems like someone else has already done it :-) (No, I didn't visit the site.) The connection strings there are for ODBC, OLE and .NET. No DBI connection strings, AFAICS. hp -- _ | Peter J. Holzer | If the code is old but the problem is new |_|_) | Sysadmin WSR / LUGA | then the code probably isn't the problem. | | | [EMAIL PROTECTED]| __/ | http://www.hjp.at/ | -- Tim Bunce on dbi-users, 2004-11-05 pgpqiTPkqt3d2.pgp Description: PGP signature
Ingres FOSS, and still more RE: DBIx::DBH - Perl extension for simplifying database connections
Christopher Hicks skrev: On Tue, 7 Dec 2004, Henrik Tougaard wrote: I (DBD::Ingres) have'nt pitched in as Jonathan voiced my concerns quite precisely, saying: Beware - DBMS are more different than anyone would like. That's why DBI has the scheme it does have - it is flexible but not easily codified. Even if its not easy a solution for migrating DSN creation out of code and into a config file would be very worthwhile. It would be worthwhile if the common parts could be factored out. Lets see, what has been under discussion till now: * host * port * db, dbname, database or whatever * user * password User and password are simple: the DBI already has a spot for those, the drivers should (and hopefully do) merge them into the DSN according to local syntax and conventions. Db is neccesary, I think we all agree on that. Host and port are the doubtful ones. Ingres has absolutely nothing that remotely resembles 'port' in it's connection. It has something called 'vnode', which could be construed as host, but that would be wrong, as it consists of both the hostname and the serverid of the DBMS-instance on that host. So calling it 'host' would be wrong and the vnode cannot be constructed given hostname and serverid, so 'vnode' is the term and calling it anything else would be A Bad Thing(R). Ingres, like Informix and (I think) Oracle, does'nt have the concept of 'host' or 'port', using other ways of adressing remote databases. Given that for most folks the support is needed for the FOSS databases ignoring the strange proprietary ways would be better than not having DSN's externalized. It seems to me that you are trying to force an extension onto the DBI based on what a small number of RDBMSs accept. When that small number just happens to be all the FOSS databases its a large enough small number. You seem to forget (I do it sometimes myself) that Ingres has joined the select group of Open Source databases a short time ago, so the small number does not include all the FOSS databases. In another message Ron Savage suggested that an on-line doc specifying all possible parameters within a DSN for each and every database supported by DBI be built up. I think that is a marvelous idea! It is often good to collect some data before doing the design. If Ron is willing to do it, I reccomend that the Driver authors send him data for their connection strings ASAP. I'll do it when I have dug through the docs - I can't remember the finer nuances of it off-hand. -- Henrik
Re: DBIx::DBH - Perl extension for simplifying database connections
On Tue, Dec 07, 2004 at 12:38:53PM -0500, Mark Stosberg wrote: On Tue, Dec 07, 2004 at 12:38:12PM +, Tim Bunce wrote: --- The simplest fix is to standardize one set of driver DSN attribute names so that at least the host, port, and database (schema) can be specified in a portable way. Most drivers already support the foo=bar;... style in the DSN string. They'd just need to support alternative names for some attributes. As for what names to use, host and port are easy choices. For the database there's db, dbname, and database. I'd probably go with db. --- So now what all you zelots out there need to do is (gently) nag the authors of your favorite drivers to implement this change. The most gentle and effective way of doing that is to send them a patch. Shouldn't DBI proper at least have a documentation patch explaining what which parts of this should be considered 'standard'? Of course. I was already working on it: @@ -2415,10 +2500,14 @@ driver is free to use whatever syntax it wants. The only requirement the DBI makes is that all the information is supplied in a single string. You must consult the documentation for the drivers you are using for a -description of the syntax they require. (Where a driver author needs -to define a syntax for the C$data_source, it is recommended that -they follow the ODBC style, shown in the last example above.) +description of the syntax they require. +It is recommended that drivers support the ODBC style, shown in the +last example above. It is also recommended that that they support the +three common names 'Chost', 'Cport', and 'Cdatabase' (plus 'Cdb' +as an alias for Cdatabase). This simplifies automatic construction +of basic DSNs: Cdbi:$driver:database=$db;host=$host;port=$port. + If the environment variable CDBI_AUTOPROXY is defined (and the driver in C$data_source is not CProxy) then the connect request will automatically be changed to: [The line numbers of the patch don't match the latest release due to other changes, but this is in the DBI-connect docs.] I see that each DBD module can translate the hash into an old-fashioned DSN string themselves. I have no plans to add dsn-as-a-hash to the DBI. Tim. p.s. I've removed [EMAIL PROTECTED] from the CC list.
Re: Ingres FOSS, and still more RE: DBIx::DBH - Perl extension for simplifying database connections
Henrik Tougaard wrote: Db is neccesary, I think we all agree on that. Almost. With Oracle the database is the usercode. Its closest equivalent to a host is the SID / TWO_TASK, but as previously mentioned - it is bad style to specify it. That specifies the instance of Oracle that you want, but it not the same as overriding the physical location of the host by passing in a host= parameter. The same story would probably hold true for any ORB located database. -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering)
RE: DBIx::DBH - Perl extension for simplifying database connections
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I really really object to the DB slot being called DB. Oracle's term tablespace is much less overused and confusing than database. An Oracle tablespace has a completely different meaning from what you think. PostgreSQL just added tablespaces, and they are in no way related to the concept of a database there either. FWIW, I added some code so the next version of DBD::Pg will accept any of db, dbname, or database inside the dsn. :) For the person compiling a list of dsn options, the canonical PG list (excluding the aliases above) can be found here: http://www.postgresql.org/docs/current/static/libpq.html Look under the PQconnectdb section. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200412080945 -BEGIN PGP SIGNATURE- iD8DBQFBtxSxvJuQZxSWSsgRAlgIAJsHc3+tuxeH85lBTEVDElqCzx/fEACg8gkI UB2Qv+wMJBj+xMscL6fhDqA= =qtiY -END PGP SIGNATURE-
Re: DBIx::DBH - Perl extension for simplifying database connections
On Mon, Dec 06, 2004 at 07:53:01PM -0500, Matthew Persico wrote: At the top of this thread and at various other entries, the point is made that many times, the parameters for connection are pulled from a source that has them listed individually. Why make the The other point, possibly more fundamental, was that various DBD drivers with similar concepts (host, port, DB name) have vastly dissimilar ways of naming them, and of joining them together into DBD strings, which is very confusing. Soo, you know that your bolts and nuts are imperial rather than metric, but were they Whitworth, BSF, UNC or something else? Nicholas Clark
Re: DBIx::DBH - Perl extension for simplifying database connections
On Mon, Dec 06, 2004 at 07:53:01PM -0500, Matthew Persico wrote:
And this, in fact is what I do at my place too.
my $dbh = connectDBI(driver = 'Oracle', user = 'foo', server =
'bar', database = 'baz'
RaiseError = 1, PrintError =0, AutoCommit = 0, driver_special =
{syb_show_sql =1, syb_show_eed=1});
Since you already have code like this, would like you to submit a patch
to DBI which works like this? :)
Mark
Re: DBIx::DBH - Perl extension for simplifying database connections
On Thu, 02 Dec 2004 08:53:38 +0100, Cosimo Streppone [EMAIL PROTECTED] wrote: Tim Bunce wrote: I know what it does, I'm trying to find real examples that demonstrate why people think it's needed. Nick has provided a good one. Any others? Something like DBIx::DBH is in use in our organization. This is because every sql source (meaning database table) is accessed with standard objects and an external definition file like: USER john PASS smith DBNAME default FILE sessions HOST my.hostname.com PORT 1521 # ... # Definition of table fields myfield1 ... bla bla blah myfield2 ... bla bla blah Thus, every piece of information needed for connection *should* be separated and a frontend is provided to be able to define new sources or modify existing sources from a browser. Then, we provide different sql driver modules, that assemble the DSN string given all the pieces. For some db servers like Sybase, DB2 (MySQL?) a use dbname is needed after connection to properly select the database. Of course this is handled by the driver class. Assuming that you're talking about IBM DB2 Universal Database, you're doing something strange and unnatural with DB2 if you have to 'use dbname' after making a connection. If you've cataloged the DB2 database in your DB2 client, the DBD::DB2 connection string syntax is simply: DBI-connect(dbi:DB2:$dbname, $user, $password); Dan
Re: DBIx::DBH - Perl extension for simplifying database connections
On Tue, 7 Dec 2004 10:58:56 +0100, Henrik Tougaard [EMAIL PROTECTED] wrote: Ingres, like Informix and (I think) Oracle, does'nt have the concept of 'host' or 'port', using other ways of adressing remote databases. So? AFAICT, what we've been talking about is simply a list of name/value pairs (a struct if you want) instead of an opaque string. Which names are required or relevant for a particular DBD is up to each DBD. The policy could simply be to ignore params you don't understand. As one earlier post said, the simplest solution is to accept a hashref instead of a string as the DSN argument to connect() It seems to me that you are trying to force an extension onto the DBI based on what a small number of RDBMSs accept. The people who want this seem to use only a few DBDs - perhaps it could be added to those? I think you're over-thinking it :) Just think of it as an exploded version of a DSN string. DSN strings can be very different, and so too can the exploded versions. -John
Re: DBIx::DBH - Perl extension for simplifying database connections
On Tue, Dec 07, 2004 at 11:13:01AM +, Nicholas Clark wrote: On Mon, Dec 06, 2004 at 07:53:01PM -0500, Matthew Persico wrote: At the top of this thread and at various other entries, the point is made that many times, the parameters for connection are pulled from a source that has them listed individually. Why make the The other point, possibly more fundamental, was that various DBD drivers with similar concepts (host, port, DB name) have vastly dissimilar ways of naming them, and of joining them together into DBD strings, which is very confusing. Soo, you know that your bolts and nuts are imperial rather than metric, but were they Whitworth, BSF, UNC or something else? Exactly. Which is why I said... --- The simplest fix is to standardize one set of driver DSN attribute names so that at least the host, port, and database (schema) can be specified in a portable way. Most drivers already support the foo=bar;... style in the DSN string. They'd just need to support alternative names for some attributes. As for what names to use, host and port are easy choices. For the database there's db, dbname, and database. I'd probably go with db. --- So now what all you zelots out there need to do is (gently) nag the authors of your favorite drivers to implement this change. The most gentle and effective way of doing that is to send them a patch. Tim.
Re: DBIx::DBH - Perl extension for simplifying database connections
On Tue, 07 Dec 2004 09:57:38 -0500, John Siracusa wrote: Hi Folks As one earlier post said, the simplest solution is to accept a hashref instead of a string as the DSN argument to connect() Well, this idea has been kicked around a bit, so I suggest it's time to do something concrete. Is there an on-line doc specifying all possible parameters within a DSN for each and every database supported by DBI? If not, then I volunteer to maintain a HTML table (of some sort) cross-tabulating database (vendors) against connection string options. Note that the effect of this is that one row, say, for a vendor would represent a hash, in that the column headings would be the key and the table entry would be the value. This means the doc would store the info as a hash, but that does not imply any implementation had to use a hash, although I suspect that's where we're headed. To build it, please email me privately samples or, at worse, references to docs per vendor. I'm planning on not (that's not) focusing primarily on abbreviated versions of DSNs, but rather on the full versions, with abbreviations listed separately. Here, I'm thinking of something like database=mydb 'v' just mydb say, within in the DSN, if such a choice is supported by a driver. I don't mind listing the alternatives, but I'm aiming for clarity in the doc, not terseness. It can then become a reference for beginners, and for me too. And yes, I do see the problem of a doc separate from the docs per driver. Such is life. Also, in case I need to read msgs from the mail archives (shudder), where do you go for archived mail on this list? Here's what I have recorded as sources of same: 1 http://www.rosat.mpe-garching.mpg.de/mailing-lists/dbi/ 2 http://www.xray.mpe.mpg.de/mailing-lists/dbi/ 3 http://xmlproj.com/fom-serve/cache/68.html Is xmlproj still sick? 4 http://groups.google.com/groups?hl=enlr=ie=UTF-8group=perl.dbi.users although I can't remember the last time I tried to use any of these references. Please tell me your preferences. -- Cheers Ron Savage, [EMAIL PROTECTED] on 8/12/2004 http://savage.net.au/index.html
Re: DBIx::DBH - Perl extension for simplifying database connections
On Tue, Dec 07, 2004 at 12:38:12PM +, Tim Bunce wrote: --- The simplest fix is to standardize one set of driver DSN attribute names so that at least the host, port, and database (schema) can be specified in a portable way. Most drivers already support the foo=bar;... style in the DSN string. They'd just need to support alternative names for some attributes. As for what names to use, host and port are easy choices. For the database there's db, dbname, and database. I'd probably go with db. --- So now what all you zelots out there need to do is (gently) nag the authors of your favorite drivers to implement this change. The most gentle and effective way of doing that is to send them a patch. Shouldn't DBI proper at least have a documentation patch explaining what which parts of this should be considered 'standard'? I see that each DBD module can translate the hash into an old-fashioned DSN string themselves. Mark
Re: DBIx::DBH - Perl extension for simplifying database connections
On Wed, 8 Dec 2004 09:00:36 +1100, Ron Savage [EMAIL PROTECTED] wrote: On Tue, 07 Dec 2004 09:57:38 -0500, John Siracusa wrote: As one earlier post said, the simplest solution is to accept a hashref instead of a string as the DSN argument to connect() With great self-restraint, I'm simply going to refer to my other posting this evening (the grump message), in the other branch of this thread (as Gmail files things). The simplest thing is to leave well alone. Well, this idea has been kicked around a bit, so I suggest it's time to do something concrete. Is there an on-line doc specifying all possible parameters within a DSN for each and every database supported by DBI? One - no. Multiple - yes. Each DBD module should document the connection strings it supports. Which one doesn't? If not, then I volunteer to maintain a HTML table (of some sort) cross-tabulating database (vendors) against connection string options. [...] Google Mail does occasionally produce a gem of an advert! ConnectionStrings.com - Forgot that connection string? You will ... www.connectionstrings.com - All connection strings in one place! Here you'll find the syntax for ... It seems like someone else has already done it :-) (No, I didn't visit the site.) -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2003.04 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: DBIx::DBH - Perl extension for simplifying database connections
On Tue, 7 Dec 2004 22:36:58 -0800, Jonathan Leffler wrote: Hi Jonathan ConnectionStrings.com - Forgot that connection string? You will ... www.connectionstrings.com - All connection strings in one place! Here you'll find the syntax for ... Excellent. Now I can retire from the fray... -- Cheers Ron Savage, [EMAIL PROTECTED] on 8/12/2004 http://savage.net.au/index.html
Re: DBIx::DBH - Perl extension for simplifying database connections
On 2004-12-06 19:53:01 -0500, Matthew Persico wrote:
And this, in fact is what I do at my place too.
my $dbh = connectDBI(driver = 'Oracle', user = 'foo', server =
'bar', database = 'baz'
RaiseError = 1, PrintError =0, AutoCommit = 0, driver_special =
{syb_show_sql =1, syb_show_eed=1});
Interesting. I do almost the opposite: I specify only one string, and
use that to read data_source, user and password from a config file.
hp
--
_ | Peter J. Holzer | If the code is old but the problem is new
|_|_) | Sysadmin WSR / LUGA | then the code probably isn't the problem.
| | | [EMAIL PROTECTED]|
__/ | http://www.hjp.at/ | -- Tim Bunce on dbi-users, 2004-11-05
pgpE1AA2vNzub.pgp
Description: PGP signature
Re: DBIx::DBH - Perl extension for simplifying database connections
On Wed, Dec 01, 2004 at 06:39:00PM +, Tim Bunce wrote: Lots of people do, it seems, but I'm not getting much background about why. FWIW, the reason I'm digging here is because I agree there may be some value in the DBI supporting something along these lines, but I need a better understanding of the underlying issues. More real- world examples would help. It'll always come down to the issue of why not store complete DSNs? and so far that's not been well covered by the feedback I've got. Here's one from a place where I used to work, where we had a very similar module to the one proposed: A given server would be set up to provide a number of backend services, including an RDBMS, a Web Server, and more. We had a number of similar servers for similar purposes, including (but not limited to) failover. To configure which server(s) to use, we had a simple config of the form server = victoria rdbms = postgres http_port = 8080 [etc] and so failing over to another server is a matter of simply changing the [server] portion., likewise (as we did for performance testing, or differing SLAs), swithcing the RDBMS used. If we had used the DSN directly, we would be duplicating information such as the hostname (and the RDBMS type, which is used elsewhere for construction admin tasks); redundancy in this form leads to frustrating silly errors consuming time (such as when one value gets changed but the another is forgotten). Mx.
Re: DBIx::DBH - Perl extension for simplifying database connections
On Fri, Dec 03, 2004 at 11:25:53AM +, Tim Bunce wrote:
Yes. It's finely balanced though. I can see merit on both sides.
The fill in a form situation is relatively common. But beyond the
MySQL/Pg model of how servers, ports, databases work there's also
the question of specifying attributes. Taking mysql as an example,
specifying mysql_client_found_rows=1 is common (or should be :)
and mysql_local_infile=1 can be needed (at least for some versions).
Then there's SSL:
mysql_ssl=1
mysql_ssl_client_key=...
mysql_ssl_client_cert=...
mysql_ssl_ca_file=...
mysql_ssl_ca_path=...
mysql_ssl_cipher=...
I wouldn't like to be filling in all that on a form. (And there's
no need to tell me there are ways to avoid specifying all those
through config files, I'm just making a general point here :)
I try to make the DBI design hit the sweet spot of general utility
(while still enabling driver-specific features in a way that's portable).
It's clear to me that the DBI hasn't quite hit the sweet spot here.
The simplest fix is to standardize one set of driver DSN attribute
names so that at least the host, port, and database (schema) can
be specified in a portable way.
Is that really the simplest? It occurs that the responses on this thread, and
in my experience, many people are comfortable familiar with the use of a
hash (/ref) for this purpose. If the connect call were to accept a hashref as
an *alternative* to the current simple string, then there would be no danger
of backwards-compatibility issues cropping up, and would fit in well with what
people are already using. That so many people have individually come to the
same solution suggests that there's something right with it.
my $dbh = DBI-connect({db = 'postgres', dbname = 'foo', port = 6767});
Mx.
Re: DBIx::DBH - Perl extension for simplifying database connections
On Mon, 6 Dec 2004 17:23:46 +, Martyn J. Pearce
[EMAIL PROTECTED] wrote:
On Fri, Dec 03, 2004 at 11:25:53AM +, Tim Bunce wrote:
Yes. It's finely balanced though. I can see merit on both sides.
The fill in a form situation is relatively common. But beyond the
MySQL/Pg model of how servers, ports, databases work there's also
the question of specifying attributes. Taking mysql as an example,
specifying mysql_client_found_rows=1 is common (or should be :)
and mysql_local_infile=1 can be needed (at least for some versions).
Then there's SSL:
mysql_ssl=1
mysql_ssl_client_key=...
mysql_ssl_client_cert=...
mysql_ssl_ca_file=...
mysql_ssl_ca_path=...
mysql_ssl_cipher=...
I wouldn't like to be filling in all that on a form. (And there's
no need to tell me there are ways to avoid specifying all those
through config files, I'm just making a general point here :)
I try to make the DBI design hit the sweet spot of general utility
(while still enabling driver-specific features in a way that's portable).
It's clear to me that the DBI hasn't quite hit the sweet spot here.
The simplest fix is to standardize one set of driver DSN attribute
names so that at least the host, port, and database (schema) can
be specified in a portable way.
Is that really the simplest? It occurs that the responses on this thread, and
in my experience, many people are comfortable familiar with the use of a
hash (/ref) for this purpose. If the connect call were to accept a hashref as
an *alternative* to the current simple string, then there would be no danger
of backwards-compatibility issues cropping up, and would fit in well with what
people are already using. That so many people have individually come to the
same solution suggests that there's something right with it.
my $dbh = DBI-connect({db = 'postgres', dbname = 'foo', port = 6767});
Mx.
And this, in fact is what I do at my place too.
my $dbh = connectDBI(driver = 'Oracle', user = 'foo', server =
'bar', database = 'baz'
RaiseError = 1, PrintError =0, AutoCommit = 0, driver_special =
{syb_show_sql =1, syb_show_eed=1});
I pull together the various bits in the call (and I support driver =
oracle too) and just call DBI-connect in the end. Since user defines
tablespace in ORacle, I ignore database- when driver eq 'Oracle'.
At the top of this thread and at various other entries, the point is
made that many times, the parameters for connection are pulled from a
source that has them listed individually. Why make the
client/programmer synthesize them - let the call do it. Yes? Make it a
requirement of the DBD implementor to take the hashed args and build
the right string and then call connect.
I do it w/o
--
Matthew O. Persico
Re: DBIx::DBH - Perl extension for simplifying database connections
On Fri, Dec 03, 2004 at 05:48:35PM +1300, Sam Vilain wrote: Ken Williams wrote: On Dec 1, 2004, at 3:48 AM, Tim Bunce wrote: I know what it does, I'm trying to find real examples that demonstrate why people think it's needed. Nick has provided a good one. Any others? Suppose someone's creating a GUI app (Perl/Tk, etc.) in which the end user fills in the server, port, user, password, and database into a screen of some sort. The back-end app will have to know how to translate that into a DBI connection string. And it's probably not reasonable to make the user understand the details of how to make a DBI connection string in this case. Can I point out that you seem to be assuming the MySQL/Pg model of how servers, ports, databases, users and passwords work. This all has no meaning to SQL*Net (Oracle), SQLite, ODBC and probably other databases, too. I suspect this is part of the reason that Tim is questioning your objectives! Yes. It's finely balanced though. I can see merit on both sides. The fill in a form situation is relatively common. But beyond the MySQL/Pg model of how servers, ports, databases work there's also the question of specifying attributes. Taking mysql as an example, specifying mysql_client_found_rows=1 is common (or should be :) and mysql_local_infile=1 can be needed (at least for some versions). Then there's SSL: mysql_ssl=1 mysql_ssl_client_key=... mysql_ssl_client_cert=... mysql_ssl_ca_file=... mysql_ssl_ca_path=... mysql_ssl_cipher=... I wouldn't like to be filling in all that on a form. (And there's no need to tell me there are ways to avoid specifying all those through config files, I'm just making a general point here :) I try to make the DBI design hit the sweet spot of general utility (while still enabling driver-specific features in a way that's portable). It's clear to me that the DBI hasn't quite hit the sweet spot here. The simplest fix is to standardize one set of driver DSN attribute names so that at least the host, port, and database (schema) can be specified in a portable way. Most drivers already support the foo=bar;... style in the DSN string. They'd just need to support alternative names for some attributes. As for what names to use, host and port are easy choices. For the database there's db, dbname, and database. I'd probably go with db. Tim.
Re: DBIx::DBH - Perl extension for simplifying database connections
On Thu, Dec 02, 2004 at 08:53:38AM +0100, Cosimo Streppone wrote: Tim Bunce wrote: I know what it does, I'm trying to find real examples that demonstrate why people think it's needed. Nick has provided a good one. Any others? Something like DBIx::DBH is in use in our organization. This is because every sql source (meaning database table) is accessed with standard objects and an external definition file like: USER john PASS smith DBNAME default FILE sessions HOST my.hostname.com PORT 1521 # ... # Definition of table fields myfield1 ... bla bla blah myfield2 ... bla bla blah Thus, every piece of information needed for connection *should* be separated and a frontend is provided to be able to define new sources or modify existing sources from a browser. Then, we provide different sql driver modules, that assemble the DSN string given all the pieces. None of that addresses the why question. All could be done by storing the DSN. Then you'd also be able to specify both DBI and driver-specific attributes, which it looks like you can't currently. Tim.
Re: DBIx::DBH - Perl extension for simplifying database connections
On Thu, Dec 02, 2004 at 03:43:56AM -, Greg Sabino Mullane wrote: It also seems like an awful lot of overhead to make a module where a couple of lines in the script will suffice. I don't really have an opinion on the module in question, but this logic seems flawed to me. I don't see how a module is a lot of overhead, even if the module is only a couple of lines long. As long as it successfully manages to encapsulate the logic into one place that can be used in many places, it seems to be that it's serving its purpose. I'd much rather not clog my scripts up with lots of scaffolding that can be hidden away elsewhere. And if you find that you end up making changes in many spots, then you should probably refactor your scripts. Such as, for example, abstracting the commonality out into a module like the one in question? Tony
Re: DBIx::DBH - Perl extension for simplifying database connections
On Wed, 1 Dec 2004 18:39:00 +, Tim Bunce [EMAIL PROTECTED] wrote: FWIW, the reason I'm digging here is because I agree there may be some value in the DBI supporting something along these lines, but I need a better understanding of the underlying issues. More real- world examples would help. It'll always come down to the issue of why not store complete DSNs? and so far that's not been well covered by the feedback I've got. I like to be able to get at the pieces in isolation. Sometimes I want to know the driver name, for example, without having to actually connect. I also like to be able to switch the database type by just changing the driver name. Looking up the DSN format is annoying. So I do it once and put it in a module. Then I just deal with the pieces without caring how they have to be assembled for a particular database. Heck, I no longer even know all the various DSN formats for the database types I deal with...and I like it that way :) -John
Re: DBIx::DBH - Perl extension for simplifying database connections
On Wed, Dec 01, 2004 at 06:39:00PM +, Tim Bunce wrote: FWIW, the reason I'm digging here is because I agree there may be some value in the DBI supporting something along these lines, but I need a better understanding of the underlying issues. More real- world examples would help. I agree solving this in DBI is ideal. DBI is about abstraction, and this is one commonly used bit that varies from database to database. It'll always come down to the issue of why not store complete DSNs? and so far that's not been well covered by the feedback I've got. I've always stored each piece as as separate config variable. Maybe it's because that's the way my brain works. I don't think what's the DSN?, I think What's the username? the port number? the host name?. I like for the software to work how I think, rather than bending my head around the format that's easiest for the computer. Mark
Re: DBIx::DBH - Perl extension for simplifying database connections
On Dec 1, 2004, at 10:39 AM, Tim Bunce wrote:
On Wed, Dec 01, 2004 at 09:56:01AM -0500, John Siracusa wrote:
On Wed, 1 Dec 2004 09:46:24 +, Tim Bunce [EMAIL PROTECTED]
wrote:
Do you generally pass URLs around as a string or broken up into a
hash?
If they had different formats for different consumers, I would. (And
even
today, I use my own URI objects when I know I'll have to do any
significant
amount of manipulation.)
I think this module is definitely useful. I already store my DSNs in
hashes
and assemble the pieces as necessary depending on the driver.
Lots of people do, it seems, but I'm not getting much background about
why.
FWIW, the reason I'm digging here is because I agree there may be
some value in the DBI supporting something along these lines, but
I need a better understanding of the underlying issues. More real-
world examples would help.
It'll always come down to the issue of why not store complete DSNs?
and so far that's not been well covered by the feedback I've got.
Tim.
I have to agree with Tim. In my DBIx::HA module that manages
high-availability and has multiple data sources per database handle,
here's how the config looks like:
$DATABASE::conf{'my_db'} = {
max_retries = 2,
db_stack = [ #format: dsn, username, password
[ 'dbi:Sybase:server=;database=A', 'user',
'pass' ]
[ 'dbi:Oracle:server=;database=B', 'u1', 'p1' ]
[ 'dbi:Pg:host=aaa;port=1212', 'u2', 'p2' ]
]
connectoninit = 0,
pingtimeout = -1,
connecttimeout = 3,
executetimeout = 20,
callback_function = \Travolta::callback_HA,
failoverlevel = 'application',
};
The DSNs are so different, and allow for so much choice, that it's just
as easy to fully qualify them.
For example, the Sybase DSN can take hostname=, scriptname=, etc...
H
Re: DBIx::DBH - Perl extension for simplifying database connections
* Tim Bunce [EMAIL PROTECTED] [2004-12-01T13:27:00] On Wed, Dec 01, 2004 at 10:09:55AM -0500, Ricardo SIGNES wrote: db_driver: ODBC db_user: kibo db_pass: grep db_name: users Why not store something like this?: db_user: kibo db_pass: grep db_dsn: dbi:...:... Well, at the least, the MSSQL ODBC driver likes to have user name in the DSN, as I recall. At any rate, it frees me from worrying every time I change something about dsn format for any given driver. I worry once when writing the dsn-string-builder, then forget about it. -- rjbs pgpD3hLGcWU8V.pgp Description: PGP signature
Re: DBIx::DBH - Perl extension for simplifying database connections
On Wed, Dec 01, 2004 at 09:46:24AM +, Tim Bunce wrote: Do you generally pass URLs around as a string or broken up into a hash? Personally I've not written much code to handle URLs. But work code has them split into hashes, built from config files where protocol, server, port, path etc are split out, so that it is easy to make a single line change that is visibly just a server (staging vs. live) while keeping all the other parts the same, or just a port, so that development machines can run server per developer. Nicholas Clark
Re: DBIx::DBH - Perl extension for simplifying database connections
Tim Bunce wrote: I know what it does, I'm trying to find real examples that demonstrate why people think it's needed. Nick has provided a good one. Any others? Something like DBIx::DBH is in use in our organization. This is because every sql source (meaning database table) is accessed with standard objects and an external definition file like: USER john PASS smith DBNAME default FILE sessions HOST my.hostname.com PORT 1521 # ... # Definition of table fields myfield1 ... bla bla blah myfield2 ... bla bla blah Thus, every piece of information needed for connection *should* be separated and a frontend is provided to be able to define new sources or modify existing sources from a browser. Then, we provide different sql driver modules, that assemble the DSN string given all the pieces. For some db servers like Sybase, DB2 (MySQL?) a use dbname is needed after connection to properly select the database. Of course this is handled by the driver class. -- Cosimo
Re: DBIx::DBH - Perl extension for simplifying database connections
Cosimo Streppone wrote: Tim Bunce wrote: I know what it does, I'm trying to find real examples that demonstrate why people think it's needed. Nick has provided a good one. Any others? Something like DBIx::DBH is in use in our organization. This is because every sql source (meaning database table) is accessed with standard objects and an external definition file like: USER john PASS smith DBNAME default FILE sessions HOST my.hostname.com PORT 1521 Sorry, the most important (and missing): DRIVER name_of_DBD_module # Informix, Sybase, DB2, Pg, ... Currently we have successfully integrated with the same code: Pg, DB2, Informix, Oracle, Sybase, Microsoft SQL (with Sybase+TDS), CSV, MySQL and we are very happy with that! -- Cosimo
Re: DBIx::DBH - Perl extension for simplifying database connections
On Thu, 2004-12-02 at 08:53, Cosimo Streppone wrote: Tim Bunce wrote: I know what it does, I'm trying to find real examples that demonstrate why people think it's needed. Nick has provided a good one. Any others? Something like DBIx::DBH is in use in our organization. This is because every sql source (meaning database table) is accessed with standard objects and an external definition file like: For some db servers like Sybase, DB2 (MySQL?) a use dbname is needed after connection to properly select the database. DBD::Sybase will do the use for you if the database name is in the DSN. Michael -- Michael Peppler Data Migrations, Inc. [EMAIL PROTECTED] http://www.peppler.org/ Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or long term contract positions - http://www.peppler.org/resume.html
Re: DBIx::DBH - Perl extension for simplifying database connections
On Dec 1, 2004, at 3:48 AM, Tim Bunce wrote: I know what it does, I'm trying to find real examples that demonstrate why people think it's needed. Nick has provided a good one. Any others? Suppose someone's creating a GUI app (Perl/Tk, etc.) in which the end user fills in the server, port, user, password, and database into a screen of some sort. The back-end app will have to know how to translate that into a DBI connection string. And it's probably not reasonable to make the user understand the details of how to make a DBI connection string in this case. -Ken
Re: DBIx::DBH - Perl extension for simplifying database connections
On Thu, Dec 02, 2004 at 09:52:20PM -0600, Ken Williams wrote: On Dec 1, 2004, at 3:48 AM, Tim Bunce wrote: I know what it does, I'm trying to find real examples that demonstrate why people think it's needed. Nick has provided a good one. Any others? Suppose someone's creating a GUI app (Perl/Tk, etc.) in which the end user fills in the server, port, user, password, and database into a screen of some sort. The back-end app will have to know how to translate that into a DBI connection string. And it's probably not reasonable to make the user understand the details of how to make a DBI connection string in this case. This all makes sense to me. But wouldn't it be easier on the users to have standards compliant DBD drivers rather than have yet another DBI shim? Other than agreeing on a standard it seems like this would be the more useful route in the long run. Austin
Re: DBIx::DBH - Perl extension for simplifying database connections
On Thu, 2 Dec 2004 03:43:56 -, Greg Sabino Mullane [EMAIL PROTECTED] wrote: This seems to be a solution in search of a problem. With the exception of perhaps port, host, and database database - Informix doesn't directly use host or port. (That's the Informix DBMS that doesn't support directly naming the host or port, so DBD::Informix can't either.) Beware - DBMS are more different than anyone would like. That's why DBI has the scheme it does have - it is flexible but not easily codified. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2003.04 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: DBIx::DBH - Perl extension for simplifying database connections
Ken Williams wrote: On Dec 1, 2004, at 3:48 AM, Tim Bunce wrote: I know what it does, I'm trying to find real examples that demonstrate why people think it's needed. Nick has provided a good one. Any others? Suppose someone's creating a GUI app (Perl/Tk, etc.) in which the end user fills in the server, port, user, password, and database into a screen of some sort. The back-end app will have to know how to translate that into a DBI connection string. And it's probably not reasonable to make the user understand the details of how to make a DBI connection string in this case. Can I point out that you seem to be assuming the MySQL/Pg model of how servers, ports, databases, users and passwords work. This all has no meaning to SQL*Net (Oracle), SQLite, ODBC and probably other databases, too. I suspect this is part of the reason that Tim is questioning your objectives! -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering)
Re: DBIx::DBH - Perl extension for simplifying database connections
On Tue, Nov 30, 2004 at 10:40:34PM +, Nicholas Clark wrote:
On Tue, Nov 30, 2004 at 10:32:12PM +, Tim Bunce wrote:
On Tue, Nov 30, 2004 at 09:38:47PM +, Nicholas Clark wrote:
On Tue, Nov 30, 2004 at 08:53:51PM +, Tim Bunce wrote:
The one that I've hit - specifying port and host, Pg vs Mysql (and
SQlite):
if ($dbspec-{driver} eq 'DBI:Pg') {
# Aaargh. Why aren't these things standarised?
$dsn = DBI:Pg:host=$dbspec-{domain};
# Aargh. W.T.F. is this case sensitivity here? It fails to connect
unless
# the name is all lowercase (as is stored within the non-case
preserving
# pg DB)
$dsn .= lc ;dbname=$dbspec-{db_name} if length $dbspec-{db_name};
$dsn .= ;port=$dbspec-{port} if defined $dbspec-{port};
} else {
$dsn .= :port=$dbspec-{port} if defined $dbspec-{port};
}
It seems to me that the problem is of your own making.
Why have separate hash elements for all these things in the first place?
Oops. 1 more line would have helped. This precedes my previous code:
my $dsn = $dbspec-{driver}:$dbspec-{db_name}:$dbspec-{domain};
Even if I keep the DSN in a flat string, I have to remember that MySQL
wants driver:DBname:hostname:port=# while Pg wants
driver:dbname:host=name;port=#
and to me needing to remember all this trivia seems wasteful.
It doesn't actually matter if its in a hash or flat string, there's too much
driver specific already even in the simple bits I would like flexibility in.
In general I find that a hash ref is useful as an argument to a function as
it provides named parameters, which avoids needing to remember a list order
for parameters, and also to have to fill in defaults to make the list up to
the position of the parameter you wish to change.
I guess I don't find it natural thinking about parameters as a single string.
Do you generally pass URLs around as a string or broken up into a hash?
Tim.
Re: DBIx::DBH - Perl extension for simplifying database connections
I know what it does, I'm trying to find real examples that demonstrate why people think it's needed. Nick has provided a good one. Any others? Tim. On Tue, Nov 30, 2004 at 06:37:01PM -0800, Terrence Brannon wrote: I don't get it. Can someone give me some small but real examples of the problem that's being solved here? well the ABSTRACT says it all... I regurgitate: quote DBIx::DBH is designed to facilitate and validate the process of creating DBI database connections. It's chief and unique contribution to this set of modules on CPAN is that it forms the DSN string for you, regardless of database vendor. Another thing about this module is that it takes a flat Perl hash as input, making it ideal for converting HTTP form data and or config file information into DBI database handles. It also can form DSN strings for both major free databases and is subclassed to support extension for other databases. DBIx::DBH provides rigorous validation on the input parameters via Params::Validate. It does not allow parameters which are not defined by the DBI or the database vendor driver into the hash /quote -- Terrence Brannon, [EMAIL PROTECTED]
Re: DBIx::DBH - Perl extension for simplifying database connections
Tim Bunce wrote: On Tue, Nov 30, 2004 at 10:40:34PM +, Nicholas Clark wrote: I guess I don't find it natural thinking about parameters as a single string. Do you generally pass URLs around as a string or broken up into a hash? Tim. quote src=http://search.cpan.org/~gaas/libwww-perl-5.802/lib/HTTP/Request/Common.pm POST 'http://www.perl.org/survey.cgi', [ name = 'Gisle Aas', email = '[EMAIL PROTECTED]', gender = 'M', born = '1964', perc = '3%', ]; /quote -- Terrence Brannon, [EMAIL PROTECTED]
Re: DBIx::DBH - Perl extension for simplifying database connections
instead of having to haul around the code to figure this out, why not create a handy documentary web service somewhere where you fill out the blanks and get an appropriate connection string? Loading a module every time you start the program just to create something that is a permanent per-installation configuration constant strikes me has if not ugly, at least hideously post-modern. I'll even donate a spot of server space to the cause if you don't have it already. On Tue, 30 Nov 2004 15:58:48 -0500, Mark Stosberg [EMAIL PROTECTED] wrote: On Tue, Nov 30, 2004 at 08:53:51PM +, Tim Bunce wrote: I don't get it. Can someone give me some small but real examples of the problem that's being solved here? To give the database name with DBD::Pg, you use: dbname=$dbname With mysql, it's different database=$database With this ConnectFoo module, it could be the same: dbname = $dbname, Mark -- David L Nicol Happy hacking! http://www.amazon.com/exec/obidos/ASIN/0596002874/tipjartransactioA/
Re: DBIx::DBH - Perl extension for simplifying database connections
On Tue, Nov 30, 2004 at 11:02:31PM -0600, David Nicol wrote: instead of having to haul around the code to figure this out, why not create a handy documentary web service somewhere where you fill out the blanks and get an appropriate connection string? Loading a module every time you start the program just to create something that is a permanent per-installation configuration constant strikes me has if not ugly, at least hideously post-modern. I'll even donate a spot of server space to the cause if you don't have it already. It's a kind offer, but does your server reach me when I'm working offline? Doubtful. But I have a local CPAN mirror, and run local database servers for development. Nicholas Clark
Re: DBIx::DBH - Perl extension for simplifying database connections
On Wed, Dec 01, 2004 at 02:02:57AM -0800, Terrence Brannon wrote: Tim Bunce wrote: On Tue, Nov 30, 2004 at 10:40:34PM +, Nicholas Clark wrote: I guess I don't find it natural thinking about parameters as a single string. Do you generally pass URLs around as a string or broken up into a hash? quote src=http://search.cpan.org/~gaas/libwww-perl-5.802/lib/HTTP/Request/Common.pm POST 'http://www.perl.org/survey.cgi', [ name = 'Gisle Aas', email = '[EMAIL PROTECTED]', gender = 'M', born = '1964', perc = '3%', ]; /quote I didn't say *can* you do that, I asked if he/you/we *generally* did that. Tim.
Re: DBIx::DBH - Perl extension for simplifying database connections
On Wed, Dec 01, 2004 at 10:09:55AM -0500, Ricardo SIGNES wrote: * Tim Bunce [EMAIL PROTECTED] [2004-12-01T04:48:40] I know what it does, I'm trying to find real examples that demonstrate why people think it's needed. Nick has provided a good one. Any others? I have a very similar set of uses to Nick's. Our model classes at work can connect to SQLite, MSSQL (ODBC) or MSSQL (ADO). We store config data as something like: db_driver: ODBC db_user: kibo db_pass: grep db_name: users It DTRT with regard to building a DSN string that contains databasename=users or Initial Catalog=users or dbname=users.db and so on. It's not the hardest problem in the world, but it's more lines to maintain. Why not store something like this?: db_user: kibo db_pass: grep db_dsn: dbi:...:... Tim.
Re: DBIx::DBH - Perl extension for simplifying database connections
At 10:39 AM 12/1/2004, you wrote:
On Wed, Dec 01, 2004 at 09:56:01AM -0500, John Siracusa wrote:
On Wed, 1 Dec 2004 09:46:24 +, Tim Bunce [EMAIL PROTECTED] wrote:
Do you generally pass URLs around as a string or broken up into a hash?
If they had different formats for different consumers, I would. (And even
today, I use my own URI objects when I know I'll have to do any significant
amount of manipulation.)
I think this module is definitely useful. I already store my DSNs in
hashes
and assemble the pieces as necessary depending on the driver.
Lots of people do, it seems, but I'm not getting much background about why.
FWIW, the reason I'm digging here is because I agree there may be
some value in the DBI supporting something along these lines, but
I need a better understanding of the underlying issues. More real-
world examples would help.
It'll always come down to the issue of why not store complete DSNs?
and so far that's not been well covered by the feedback I've got.
Hi,
In our case we have several databases in a replication line using mysql. In
some cases we might want to connect to a server other than the first in
line, but most often we connect to the first in line/master. I also wanted
to make sure that if the script happened to be running on the master local
host that it would not connect using the host name and end up using TCP on
localhost.
Does that make any sense? I am not sure now that I think about it why I
could not just store the DSN for everything, but only separate out the
hostname. But then that is all I am doing anyway.
+-+---+--+-+-+---+
| Field | Type | Null | Key | Default | Extra |
+-+---+--+-+-+---+
| dbname | varchar(40) | | PRI | | |
| dborder | tinyint(2)| YES | | NULL| |
| ip | varchar(15) | | MUL | 0 | |
| servername | varchar(100) | | PRI | | |
| username| varchar(20) | | | | |
| password| varchar(20) | | | | |
| raise_error | enum('1','0') | | | 1 | |
| autocommit | enum('1','0') | | | 1 | |
+-+---+--+-+-+---+
I don't use the IP right now, but record it anyway. The server name is
important because I use the localhost name to match up with that, and if it
matches then don't add in the hostname to the connect string.
I just looked at DBIx::DBH and I have to say I don't get it. Why is that
any easier than the default?
I thought at first this thread was talking about managing connections..
Thanks,
Eric
Tim.
Re: DBIx::DBH - Perl extension for simplifying database connections
On Dec 1, 2004, at 10:39 AM, Tim Bunce wrote:
On Wed, Dec 01, 2004 at 09:56:01AM -0500, John Siracusa wrote:
On Wed, 1 Dec 2004 09:46:24 +, Tim Bunce [EMAIL PROTECTED]
wrote:
Do you generally pass URLs around as a string or broken up into a
hash?
If they had different formats for different consumers, I would. (And
even
today, I use my own URI objects when I know I'll have to do any
significant
amount of manipulation.)
I think this module is definitely useful. I already store my DSNs in
hashes
and assemble the pieces as necessary depending on the driver.
Lots of people do, it seems, but I'm not getting much background about
why.
FWIW, the reason I'm digging here is because I agree there may be
some value in the DBI supporting something along these lines, but
I need a better understanding of the underlying issues. More real-
world examples would help.
It'll always come down to the issue of why not store complete DSNs?
and so far that's not been well covered by the feedback I've got.
Tim.
I have to agree with Tim. In my DBIx::HA module that manages
high-availability and has multiple data sources per database handle,
here's how the config looks like:
$DATABASE::conf{'my_db'} = {
max_retries = 2,
db_stack = [ #format: dsn, username, password
[ 'dbi:Sybase:server=;database=A', 'user',
'pass' ]
[ 'dbi:Oracle:server=;database=B', 'u1', 'p1' ]
[ 'dbi:Pg:host=aaa;port=1212', 'u2', 'p2' ]
]
connectoninit = 0,
pingtimeout = -1,
connecttimeout = 3,
executetimeout = 20,
callback_function = \Travolta::callback_HA,
failoverlevel = 'application',
};
The DSNs are so different, and allow for so much choice, that it's just
as easy to fully qualify them.
For example, the Sybase DSN can take hostname=, scriptname=, etc...
H
Re: DBIx::DBH - Perl extension for simplifying database connections
On Thu, Dec 02, 2004 at 08:34:20AM +1100, Ron Savage wrote: On Wed, 1 Dec 2004 18:39:00 +, Tim Bunce wrote: H Tim need a better understanding of the underlying issues. More real- world examples would help. Here's a real world example of how I do things, although I am in no way convinced that such a module as we are discussing is needed... Presumably because, like me, you tend to use entire DSN strings rather than trying to construct them from parts: Class - new(site = 'local') to Class - new(site = 'remote'), and use that to index into a hash to get the connexion parameters. local = ['dbi:mysql:db_name1:127.0.0.1', 'username1', 'password1'], remote = ['dbi:mysql:db_name2:dbhost.quadrahosting.com.au', 'username2', 'password2'], Tim.
Re: DBIx::DBH - Perl extension for simplifying database connections
On Wed, Dec 01, 2004 at 01:45:50PM -0500, John Siracusa wrote: On Wed, 1 Dec 2004 18:39:00 +, Tim Bunce [EMAIL PROTECTED] wrote: FWIW, the reason I'm digging here is because I agree there may be some value in the DBI supporting something along these lines, but I need a better understanding of the underlying issues. More real- world examples would help. It'll always come down to the issue of why not store complete DSNs? and so far that's not been well covered by the feedback I've got. I like to be able to get at the pieces in isolation. Sometimes I want to know the driver name, for example, without having to actually connect. FYI see DBI-parse_dsn(...) I also like to be able to switch the database type by just changing the driver name. Looking up the DSN format is annoying. So I do it once and put it in a module. Then I just deal with the pieces without caring how they have to be assembled for a particular database. Heck, I no longer even know all the various DSN formats for the database types I deal with...and I like it that way :) Okay. Thanks. Tim.
Re: DBIx::DBH - Perl extension for simplifying database connections
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This seems to be a solution in search of a problem. With the exception of perhaps port, host, and database, the dsn arguments are pretty DBMS-specific, meaning that they cannot really be mapped from one DBD to another, nor can any common rules be devised. It also seems like an awful lot of overhead to make a module where a couple of lines in the script will suffice. And if you find that you end up making changes in many spots, then you should probably refactor your scripts. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200412011017 -BEGIN PGP SIGNATURE- iD8DBQFBreFbvJuQZxSWSsgRAlRJAJ42f13jjfnKIJmGIXSprl/z+D5QYACeOOmx 4pa9XkRCDqYPxC6kJ95vqHE= =mDCA -END PGP SIGNATURE-
Re: DBIx::DBH - Perl extension for simplifying database connections
On Tue, Nov 30, 2004 at 07:21:11AM -0800, Terrence Brannon wrote: Mark Stosberg wrote: On Tue, Nov 30, 2004 at 07:38:34AM +, Terrence Brannon wrote: NAME DBIx::DBH - Perl extension for simplifying database connections I suggest 'DBIx::DSN' as a better name, since database handles (DBH) are universally used in DBI-based projects. Thanks for the input Mark. The only thing is, the functionality of the module is to provide database handles (DBHs) or @connect_data, which equals ($dsn, $user, $pass, $attr) So DSN is too restrictive. Perhaps DBIx::DBH::from_hash ... well who knows. I dont understand your comment: ... since database handles (DBH) are universally used in DBI-based project --- why is that an issue? Their is no chance of trampling on another's namespace is there? The point is that DBIx::DBH is practically meaningless. DBIx::DSN is better, but only slightly. Try something like DBIx::FooConnect or DBIx::ConnectFoo where Foo is something that gives at least a clue about what the modules does. I like the idea, having written if/else chains in the past to solve the same problem. yeah, there is certainly a maze of things to polymorphically wind your way through when getting the DBI attributes and driver-dsn and driver-attributes to all meld together. I don't get it. Can someone give me some small but real examples of the problem that's being solved here? Tim.
Re: DBIx::DBH - Perl extension for simplifying database connections
On Tue, 30 Nov 2004 20:53:51 +, Tim Bunce wrote: Hi Folks So DSN is too restrictive. Perhaps DBIx::DBH::from_hash ... well who knows. [snip] The point is that DBIx::DBH is practically meaningless. DBIx::DSN is better, but only slightly. Try something like DBIx::FooConnect or DBIx::ConnectFoo where Foo is something that gives at least a clue about what the modules does. How about DBIx::DBHFactory or ::DSNFactory, then, if any such module is needed (see below)? I don't get it. Can someone give me some small but real examples of the problem that's being solved here? Seconded. -- Cheers Ron Savage, [EMAIL PROTECTED] on 1/12/2004 http://savage.net.au/index.html
Re: DBIx::DBH - Perl extension for simplifying database connections
So DSN is too restrictive. Perhaps DBIx::DBH::from_hash ... well who knows. I dont understand your comment: ... since database handles (DBH) are universally used in DBI-based project --- why is that an issue? Their is no chance of trampling on another's namespace is there? All DBI modules use database handles, so how is your handling special? 'from_hash' does clarify that. Although hashes are used as part the connect routine already. The key service here is that you are providing a single interface to connect to any database. I also thought of DBIx::Connect ... but it looks like you already published that one. :) I revise my suggestion to be: DBIx::UnifiedConnect Mark
Re: DBIx::DBH - Perl extension for simplifying database connections
On Tue, Nov 30, 2004 at 08:53:51PM +, Tim Bunce wrote: I don't get it. Can someone give me some small but real examples of the problem that's being solved here? To give the database name with DBD::Pg, you use: dbname=$dbname With mysql, it's different database=$database With this ConnectFoo module, it could be the same: dbname = $dbname, Mark
Re: DBIx::DBH - Perl extension for simplifying database connections
On Tue, Nov 30, 2004 at 08:53:51PM +, Tim Bunce wrote:
I don't get it. Can someone give me some small but real examples
of the problem that's being solved here?
The one that I've hit - specifying port and host, Pg vs Mysql (and SQlite):
if ($dbspec-{driver} eq 'DBI:Pg') {
# Aaargh. Why aren't these things standarised?
$dsn = DBI:Pg:host=$dbspec-{domain};
# Aargh. W.T.F. is this case sensitivity here? It fails to connect unless
# the name is all lowercase (as is stored within the non-case preserving
# pg DB)
$dsn .= lc ;dbname=$dbspec-{db_name} if length $dbspec-{db_name};
$dsn .= ;port=$dbspec-{port} if defined $dbspec-{port};
} else {
$dsn .= :port=$dbspec-{port} if defined $dbspec-{port};
}
Nicholas Clark
Re: DBIx::DBH - Perl extension for simplifying database connections
On Tue, Nov 30, 2004 at 10:32:12PM +, Tim Bunce wrote:
On Tue, Nov 30, 2004 at 09:38:47PM +, Nicholas Clark wrote:
On Tue, Nov 30, 2004 at 08:53:51PM +, Tim Bunce wrote:
The one that I've hit - specifying port and host, Pg vs Mysql (and SQlite):
if ($dbspec-{driver} eq 'DBI:Pg') {
# Aaargh. Why aren't these things standarised?
$dsn = DBI:Pg:host=$dbspec-{domain};
# Aargh. W.T.F. is this case sensitivity here? It fails to connect
unless
# the name is all lowercase (as is stored within the non-case preserving
# pg DB)
$dsn .= lc ;dbname=$dbspec-{db_name} if length $dbspec-{db_name};
$dsn .= ;port=$dbspec-{port} if defined $dbspec-{port};
} else {
$dsn .= :port=$dbspec-{port} if defined $dbspec-{port};
}
It seems to me that the problem is of your own making.
Why have separate hash elements for all these things in the first place?
Oops. 1 more line would have helped. This precedes my previous code:
my $dsn = $dbspec-{driver}:$dbspec-{db_name}:$dbspec-{domain};
Even if I keep the DSN in a flat string, I have to remember that MySQL
wants driver:DBname:hostname:port=# while Pg wants
driver:dbname:host=name;port=#
and to me needing to remember all this trivia seems wasteful.
It doesn't actually matter if its in a hash or flat string, there's too much
driver specific already even in the simple bits I would like flexibility in.
In general I find that a hash ref is useful as an argument to a function as
it provides named parameters, which avoids needing to remember a list order
for parameters, and also to have to fill in defaults to make the list up to
the position of the parameter you wish to change.
I guess I don't find it natural thinking about parameters as a single string.
Nicholas Clark
Re: DBIx::DBH - Perl extension for simplifying database connections
Tim Bunce wrote: On Tue, Nov 30, 2004 at 07:21:11AM -0800, Terrence Brannon wrote: I don't get it. Can someone give me some small but real examples of the problem that's being solved here? well the ABSTRACT says it all... I regurgitate: quote DBIx::DBH is designed to facilitate and validate the process of creating DBI database connections. It's chief and unique contribution to this set of modules on CPAN is that it forms the DSN string for you, regardless of database vendor. Another thing about this module is that it takes a flat Perl hash as input, making it ideal for converting HTTP form data and or config file information into DBI database handles. It also can form DSN strings for both major free databases and is subclassed to support extension for other databases. DBIx::DBH provides rigorous validation on the input parameters via Params::Validate. It does not allow parameters which are not defined by the DBI or the database vendor driver into the hash /quote -- Terrence Brannon, [EMAIL PROTECTED]
