in reply to Re^6: DBI placeholders for spatial data
in thread DBI placeholders for spatial data

I think this is the important part of the documentation

As a convenience, if the $data_source parameter is undefined or empty, the DBI will substitute the value of the environment variable DBI_DSN. If just the driver_name part is empty (i.e., the $data_source prefix is "dbi::"), the environment variable DBI_DRIVER is used. If neither variable is set, then connect dies.

The first sentence does not apply, because $data_source is neither undefined nor empty. The second sentence does not apply, because $data_source does not start with "dbi::". The third sentence does not apply, because neither the first nor the second sentence applied.

I guess that the environment variable DBI_DRIVER is set to mysql as that is the RDBMS installed on the server.

Guess? How about printing the environment instead of guessing? Run env or perl -e 'print "$_=$ENV{$_}\n" for keys %ENV' from a shell for a list of all environment variables; perl -e 'print "$_=$ENV{$_}\n" for sort grep /^DBI_/,keys %ENV' to just list those starting with DBI_. From a CGI context, run something like this:

#!/bin/bash echo -en "Content-Type: text/plain\r\n\r\n" env

Or this:

#!/usr/bin/perl -T use strict; use warnings; use Data::Dumper; print "Content-Type: text/plain\r\n\r\n", Data::Dumper->new([\%ENV],['*ENV'])->Sortkeys(1)->Useqq(1)->Du +mp();

Why should installing MySQL set a DBI-specific environment variable? MySQL does not do so out of the box, and I would be rather surprised if any of the major Linux or *BSD distributions would do so. It does not make any sense, simply because you may have more than one database on your system.

According to your logic, installing the SQLite library should automatically set $ENV{'DBI_DRIVER'}='SQLite', system-wide. Installing PostgreSQL should set it to 'Pg'. Installing MariaDB should set it to 'MariaDB'. Which one wins if I install PostgreSQL for the main work and SQLite to read some application database like, for example, Firefox bookmarks? The database installed first? The database installed last? Given that DBD::MariaDB does not only support MariaDB, but also MySQL, and it fixes a lot of problems of DBD::mysql, why should installing MySQL set $ENV{'DBI_DRIVER'}='mysql' instead of $ENV{'DBI_DRIVER'}='MariaDB'?

Let's assume your idea was real. Installing MySQL sets $ENV{'DBI_DRIVER'}='mysql'. Assume a very bare system, just enough to get MySQL running, plus Perl and DBI. Perl scripts would rely on $ENV{'DBI_DRIVER'}. Now, SQLite is installed as a dependency to support Firefox or any other application using SQLite database files. Following the same logic, installing SQLite forcefully sets $ENV{'DBI_DRIVER'}='SQLite'. Now all existing perl scripts would break just because you installed some completely independent software that has nothing to do with MySQL, or Perl, or DBI. It just installed another relational database. Wouldn't that be great? Imgine the hordes of users assembling in front of the home of whoever came up with that great idea, to celebrate it with torches, pitchforks, and some barrels containing tar and feathers.


Update:

You seem to trigger a bug in DBI->connect(), see Re^8: DBI placeholders for spatial data.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Replies are listed 'Best First'.
Re^8: DBI placeholders for spatial data
by Bod (Curate) on Jun 30, 2021 at 20:28 UTC
    Guess? How about printing the environment instead of guessing?

    I guess because the DBI environment variables are not available to me on the shared hosting!

    There is a script in my cgi-bin which lists all the CGI environment variables and there is nothing helpful in there. When I connect by SSH and run perl -e 'foreach $k(keys %ENV){print "$k - $ENV{$k}\n";}' I get environment variables for SSH and for local PERL and other directories but nothing relating to DBI

    So, as it is hidden from me by the server admins, I can only guess...

      I guess because the DBI environment variables are not available to me on the shared hosting!

      There is a script in my cgi-bin which lists all the CGI environment variables and there is nothing helpful in there. When I connect by SSH and run perl -e 'foreach $k(keys %ENV){print "$k - $ENV{$k}\n";}' I get environment variables for SSH and for local PERL and other directories but nothing relating to DBI

      Of course you won't see the web server environment variables when running code from an SSH shell.

      So, as it is hidden from me by the server admins, I can only guess...

      Nonsense. When you run from the web server, i.e. a CGI or something running via mod_perl, you will see exactly the same variables as Perl. There is no way to hide anything. If DBI can see an environment variable, so can any other perl code started by the web server.

      Depending on how your shared hosting is configured, your CGIs may actually be run via mod_perl, using ModPerl::Registry. Loading Apache::DBI from the webserver may also happen. That changes how DBI->connect() works, as documented in Apache::DBI. The documentation also gives a hint how to detect that situation: $ENV{'MOD_PERL'} is set and $INC{'Apache/DBI.pm'} should exist.

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)