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

I wanted to access a mysql-Database from perl. Use DBI. Ok. Now perl wants to load DBD::mysql. Go to CPAN and fetch it. make test fails! Huh?
Now the fun begins:
First test failed because it could not connect to the server. Because on this server user root doesn't exist. Look at the source: DBI_USER and DBI_PASS are for this. Set the vars. Futile: make test doesn't give them to perl.

Create user root. Tests fail again: misnumbered tests? Or genuine fails?
But some light: cc warns about double definition of "do" and "rows".

Ok, try older version (3.0007). Does not compile. Parse error at rows(Line 2390). Looking at the source: nothing obvious(Line reads "my_ulonglong rows= 0;" And no silly games with forgotten semicola.

Go still older (3.0006). Same results as 3.0008.

Try this: mysql is quite old, try some 2.x version. Yes it works.


So my question is: Will DBD-mysql-3* ever work with older mysql versions?

Replies are listed 'Best First'.
Re: Mysql 3.23.58 and DBD::mysql
by jonadab (Parson) on Nov 15, 2006 at 13:55 UTC
    First test failed because it could not connect to the server. Because on this server user root doesn't exist.

    This is exactly the sort of situation force install is intended to solve. You know why the test is failing, so just tell CPAN.pm to ignore the failed test and install anyway. If, after installation, you find that the module really doesn't work, you can then uninstall it, but many times (I would say at least half the time, in my experience) when a test fails, it's the test that's broken, not the module itself. This is especially likely to be the case in this sort of situation, wherein you know why the test is failing.

    On the other hand, it does also make sense that if MySQL is really really old you might have to use an older version of DBD::mysql with it, or else upgrade MySQL.

    Of course, "really old" is relative. There's really old as in, "I've got a really old version of Wine on my Gentoo box. I haven't emerged it it in, like, a month or two", and then there's "I've got a really old version of Firefox on my workstation, so old that it's called Firebird", and then there's "My production server has some really old versions of things, because I haven't had time to migrate it from woody to sarge yet", and then there's "This crusty old SunOS box has a really old version of sendmail. I think it's the version that came with the OS." Since you didn't give us the actual version number of your "really old" version of MySQL, it's hard to know whether it's really so old that it's reasonable for DBD::mysql to not support it.


    Sanity? Oh, yeah, I've got all kinds of sanity. In fact, I've developed whole new kinds of sanity. You can just call me "Mister Sanity". Why, I've got so much sanity it's driving me crazy.
      Yes, I know why SOME tests failed. That doesn't say anything about the others, that were scrolled too quickly from the screen to check for their reasons. And if a test fails because of "no privilege" it doesn't say anything about whether the test would have succeeded (and therefore whether my program would work) if it could have connected. So a test that fails out of reasons I know (and can't correct) doesn't say me whether I should make install. (Besides I didn't find any docs about how to force install -- cmd-line or ENV or ... --)
        That doesn't say anything about the others, that were scrolled too quickly from the screen to check for their reasons.

        So, scroll back?

Re: Mysql 3.23.58 and DBD::mysql
by davorg (Chancellor) on Nov 15, 2006 at 13:18 UTC

    The README file that comes with the latest version contains information about getting support for DBD::mysql. There's a mailing list at perl@lists.mysql.com and it also lists the author's email address.

    I would think that either of those two avenues would be more productive than venting on Perl Monks :-)

    --
    <http://dave.org.uk>

    "The first rule of Perl club is you do not talk about Perl club."
    -- Chip Salzenberg