On Fri, 21 Apr 2006 12:36:43 +0200, Dr.Ruud wrote:
Hi
> your code. So we're back at:
>
> /\A(?:mysql|pg)\z/i
> /\A(?i:mysql|pg)\z/
Nope. Wrong again. Notice a pattern developing here?
DSNs 101: A Tutorial Based on My Crude Level of Understanding
My CGI programs normally have up to 3 distinct types of DSNs:
o An 'ODBC DSN'
o A 'DBI DSN'. This is also known as a 'DBI connexion string'
o A 'CGI::Session DSN'
When discussing DBI matters, we can ignore those of type 'CGI::Session DSN'.
Further, for simplicity let's confine ourselves to Postgres. MySQL would do just
as well.
For a database called 'staff', say, typical values for these DSNs might be:
o 'ODBC DSN' => 'pg-staff'
o 'DBI DSN' => 'dbi:Pg:dbname=staff' or 'dbi:ODBC:pg-staff'
So, 'Convention # 1' is that 'ODBC DSN's contain a string to represent the
database vendor, here 'pg', and a string to represent to database, here 'staff'.
Now, if we wish to write code conditional upon on the vendor, as in my earlier
post of this now over-extended thread, i.e. as in my now infamous 'sub
last_insert_id()', what do we do?
What /I/ do is to break the problem down into simple steps.
Step 1: Abstract out the 'DBI DSN' processing code into a method, let's call it
'sub parse_dsn()', which stores data, including a vendor-identifier, into a
place where other code, let's call it 'sub vendor()', can access it.
In the case of 'DBI DSN' => 'dbi:Pg:dbname=staff', I store 'Pg'.
In the case of 'DBI DSN' => 'dbi:ODBC:pg-staff', I store 'Pg'.
Notice a pattern developing here?
So, 'Convention # 2' is that 'DBI DSN' processing code is done in one place,
inside 'sub parse_dsn()'.
And, 'Convention # 3' is that Postgres is uniquely identified, independently of
the 'DBI DSN', as 'Pg'.
And, 'Convention # 4' is that the return value of 'sub vendor()', will be such
an identifier, here 'Pg'.
Step 2: Now, when yet other code, let's call it 'sub last_insert_id()', wants to
execute the aforesaid and understated conditional code, it can do this:
if ($self -> db_vendor() =~ /(?:mysql|Pg)/)
{
...
}
Neat, huh?
This uses non-capturing parentheses to emulate:
if ( ($self -> db_vendor() eq 'mysql') || ($self -> db_vendor() eq
'Pg') )
{
...
}
but that contains 2 method calls instead of the regexp, so we could have
written:
my($vendor) = $self -> db_vendor();
if ( ($vendor eq 'mysql') || ($vendor eq 'Pg') )
{
...
}
That's the funny thing about Perl, there can be more than one way to do things.
So, Dr. Ruud, I'd like to think that by this time you have seen that your
fundamental mistake was to persist with code suggestions, including colons no
less!, which were based on the delusion that 'sub last_insert_id()' was parsing
a 'DBI DSN', when in fact there was no such DSN within the scope of that sub.
Specifically, 'sub vendor()', by virtue of its well-chosen name (but I'm
biased), could reasonably be expected to limit its activities to vendor names.
If I had called it 'sub dbi_connexion_string()', understandable confusion may
have followed. Confusion did follow, but I can't really say it's understandable.
Permit me to finish with 3 suggestions:
o For more on 'DBI connexion strings', the DBI docs, and:
http://www.connectionstrings.com/
o Fell free to donate large quantities of money to the
Perl DBI Development Fund, at (watch wrap):
https://donate.perlfoundation.org/index.pl?node=Fund%20Drive%20Status&selfund=10
2
o This thread is closed, ended, finished, shut down, terminated, etc, as
previously noted
--
Cheers
Ron Savage, [EMAIL PROTECTED] on 22/04/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company
