ChrisOfVa has asked for the wisdom of the Perl Monks concerning the following question:

Hello Monk’s. I have been tasked with updating a large windows web application from Perl 5.10 32bit to the latest Perl 5.26.1 64bit, all has gone well until I get to one problem. Under 5.10 the original programmer stored the DBI connection in a custom $ENV variable which is then used in many files for database calls and due to the amount of calls it would be extremely hard to update it everywhere. I wanted to show the dumper information and see if maybe I could understand it better and if there was a solution without modifying all of the files. Example for the variable $ENV{'dbh_connection'}

For Perl 5.10 32 bit, the dumper returns: 
$foo = bless( {}, 'DBI::db' );

[download]

For Perl 5.26.1 64 bit, the dumper returns: 
$foo = 'DBI::db=HASH(0x4ad63e8)';

[download]

If I use a standard variable such as $db_con it will return: 
$foo = bless( {}, 'DBI::db' );

[download]

Thank you ahead of time for all of your help and information.

Replies are listed 'Best First'.
Re: Custom $ENV after upgrade not holding DBI connection
by Corion (Patriarch) on Aug 23, 2018 at 14:43 UTC

    See perlvar on %ENV:

    As of v5.18.0, both keys and values stored in %ENV are stringified.

    The solution is to not store the database connection in %ENV but to store it in some other global variable or to write a function that stores the connection:

    sub get_dbh {
    state $dbh ||= connect_dbh( ... );
}

    [download]
[reply]
[d/l]
[select]

      I did not know about state! Thanks. (Previously I said I knew perl 40% now I will get this down to 30)

      To the point, how does passing a DBI connection object around separate perl programs should work in the first place? Either by saving it as a string to a (ENV) variable or serialising it and saving it to a file? I do assume you pass said object around different perl executables/programs because you talk about the ENV right?

      I have just used Sereal to save a DB connection object to file and read again. It works (i guess fine, tested read-only and from the same executable instance, i.e. create, save, read, execute all in same executable) as far as executing statements. It returns same results as original handle. But when it comes to disconnect() I get a nasty is not a DBI handle (has no magic) (nasty in the sense that it spits out from the guts its SV, RV, IV...

      And expectedly I guess because in retrospect I read from DBI:

      If you try to create your own handles using bless() then you'll find the DBI will reject them with an "is not a DBI handle (has no magic)" error.

      So, is there a best practice to share DB connection objects among separate perl executables or is something not possible and I misunderstood the setting?

      And btw that's probably a bug in Sereal not treating DBI connection objects specially?

      bw, bliako

      Edit/Update: I can also report that the de-serialised db connection object (the one read from file) is cleaned up automatically when out-of-scope.

[reply]
[d/l]
[select]
      Thank you very much sir.
[reply]

Back to Seekers of Perl Wisdom