Beefy Boxes and Bandwidth Generously Provided by pair Networks RobOMonk
Perl Monk, Perl Meditation
 
PerlMonks  

Re^6: Change in Berkeley DB in Perl 5.12?

by RobbieSnr (Novice)
on Nov 06, 2011 at 10:08 UTC ( #936258=note: print w/ replies, xml ) Need Help??


in reply to Re^5: Change in Berkeley DB in Perl 5.12?
in thread Change in Berkeley DB in Perl 5.12?

Ah, I see, thanks.

Unfortunately I am using one of 1&1's servers and have no access to these utilities which don't seem to be available from the DB_File module. There must be others in the same position as I am, who have no knowledge of how Berkeley DB works and who are just using DB_FIle to create hash database files. They would expect a Perl upgrade to be backwards compatible and won't understand why they can't now access their database files. I also thought that newer versions of the DB engine would also be backward compatible and did check the Oracle forum to see if there were any problems in this respect and there didn't seem to be. I did know that you can't transfer one of these database files from one computer to another but here they were on the same machine.

There is no mention of possible problems in the DB_FIle CPAN page if the DB engine is upgraded and that this needs to be checked. This Perl module is only intended to be used for the facilities provided by Berekely DB version 1x and the ActiveState distribution of their ActivePerl only links DB_FIle to version 1 of the DB engine. It's unfortunate that the version of this Perl module that is installed from CPAN can't be adjusted so that it follows this practice.


Comment on Re^6: Change in Berkeley DB in Perl 5.12?
Re^7: Change in Berkeley DB in Perl 5.12?
by Anonymous Monk on Nov 06, 2011 at 23:55 UTC

    Unfortunately I am using one of 1&1's servers and have no access to these utilities which don't seem to be available from the DB_File module.

    Excuses excuses :) weak excuses :)

    There must be others in the same position as I am, who have no knowledge of how Berkeley DB works and who are just using DB_FIle to create hash database files.

    Yes, ignorance is default state :)

    They would expect a Perl upgrade to be backwards compatible and won't understand why they can't now access their database files.

    Unless your ticket promises a free lunch , its naive to expect a free lunch -- applies to transportation and computers :)

    Truism of computer software, before deploying upgrade, check Changelog, run your test suite (verify assumptions/contract), verify your backups

    I also thought that newer versions of the DB engine would also be backward compatible and did check the Oracle forum to see if there were any problems in this respect and there didn't seem to be.

    AFAIK, the db utilities are the backwards compatibility layer

    I did know that you can't transfer one of these database files from one computer to another

    <raiseEyebrow>How did you learn that exactly, intuition?</raiseEyebrow>

    :D

    ...but here they were on the same machine. There is no mention of possible problems in the DB_FIle CPAN page if the DB engine is upgraded and that this needs to be checked.

    I think this qualifies http://search.cpan.org/dist/DB_File/DB_File.pm#Using_DB_File_with_Berkeley_DB_version_2_or_greater

    Note: The database file format has changed multiple times in Berkeley DB version 2, 3 and 4. If you cannot recreate your databases, you must dump any existing databases with either the db_dump or the db_dump185 utility that comes with Berkeley DB. Once you have rebuilt DB_File to use Berkeley DB version 2 or greater, your databases can be recreated using db_load. Refer to the Berkeley DB documentation for further details.

     

    This Perl module is only intended to be used for the facilities provided by Berekely DB version 1x and the ActiveState distribution of their ActivePerl only links DB_FIle to version 1 of the DB engine.

    How did you reach that conclusion?

    For example, DB_File typically isn't available on win32 by default (since libdb isn't), this is also true for ActivePerl-5.14.2.1402-MSWin32-x86-295342

    It's unfortunate that the version of this Perl module that is installed from CPAN can't be adjusted so that it follows this practice.

    I doubt such a practice exists :)

    If you wish to link to a particular version of lidbd, like say http://www.cpan.org/src/misc/db.1.86.tar.gz, all you have to do is install it, and tell Makefile.PL to link to it (maybe edit http://cpansearch.perl.org/src/PMQS/DB_File-1.824/config.in)

    No, I'm not the Grinch

      I've been using DB_FIle for over 10 years now. I was aware early on, from experience not intuition, that DBM files can't be ported, and found this was confirmed in one of my early books on Perl, by Martin C Brown in 2001. In that time I've run CGI scripts on various servers and never had any problems until now with DB_FIle.

      I don't have administration rights on the server that's running the particular script that had this problem so I couldn't do other than accept the changes that were made. There was no mention made of a change to the version of the DB engine that was going to be used by so I couldn't possibly test what the result of the changes would be beforehand. I did check that the script would run under Perl 5.10, there was nothing in the Changelog to suggest otherwise, but this was using my local version of Perl, the one distributed by ActiveState, which sensibly used version 1 of the DB engine for its DB_File

      The documentation for DB_File from which you've already quoted confirms that DB_FIle is intended to be used with version 1 of the DB engine, and while it can be tied to other versions "the interface is limited to the functionality provided by Berkeley DB 1.x". The BerkeleyDB module is the one to use if the features of later versions of the engine are required.

      One question perhaps you can answer. Do the other distributions of Perl and this DB_File module come with that module linked to a particular version of the Berkeley DB engine, or is it left to the server administrator to decide which version of the DB engine he/she is going to use?

          Do the other distributions of Perl and this DB_File module come with that module linked to a particular version of the Berkeley DB engine, or is it left to the server administrator to decide which version of the DB engine he/she is going to use?

        If you are using DB_File, it should only be used with Version 1.x which is in the public domain. All other versions from BerkeleyDB 2.0 on, are owned by Oracle. If your version of DB_File is using a version other than 1.x, then there may be licensing and royalty issues.

        I have moved BerkeleyDB data bases from big-endian to little-endian machines without a problem for 3.x versions, but for the 4.x and 5.x (Oracle) versions, I need to export the data and then import the data on the target machine. I never tried it with DB_File, since I have never been able to get DB_File to work correctly in a multi-user environment.

        Hope this helps!

        "Well done is better than well said." - Benjamin Franklin

        One question perhaps you can answer. Do the other distributions of Perl and this DB_File module come with that module linked to a particular version of the Berkeley DB engine, or is it left to the server administrator to decide which version of the DB engine he/she is going to use?

        Yes, it is left to the server administrator, as it depends entirely on what version of libdb is installed

        If the system on which it is being installed, doesn't have libdb, then DB_File won't be installed

        If you view http://ppm4.activestate.com/author/PMQS.html you can see, that on some platforms DB_File is available, while it isn't on other platforms

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://936258]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (16)
As of 2014-04-17 16:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (453 votes), past polls