Mysql-ruby won't connect

unknown · January 2, 2007, 8:51am

I’m trying to get my first ruby box set up. I’m so far unable to
connect to the mysql database with mysql-ruby.

I’m on an Intel Mac, running macosx tiger 10.4.8. At first, I couldn’t
even compile the plugin, there is some bug in the software. It gave an
error like

mysql.c: In function ‘Init_mysql’:
mysql.c:2015: error: ‘ulong’ undeclared (first use in this function)

After googling around, I found that this error is known, and can be
fixed by simply declaring that variable in mysql.c. See
http://www.maxdunn.com/typo/articles/2006/12/12/installing-mysql-gem-on-mac-os-x-10-4
or

or
http://www.planetrubyonrails.org/show/feed/11
for details.

After declaring that variable, the software compiled successfully, but
was unable to connect to the database. When I run the test file with

$ /usr/local/bin/ruby test.rb localhost root password

I get 180 errors all looking something like

Error:
test_sqlstate(TC_MysqlStmt2):
Mysql::Error: Access denied for user ‘lethe’@‘localhost’ (using
password: NO)
test.rb:441:in new' test.rb:441:in setup’

I notice that it’s not trying to connect with the username and password
I specified on the command line. “lethe” is my account login, whereas
my sql login is “root”. And it’s not specifying a password. Perhaps
listing host, user, and password on the command line is not the right
way to specify for test.rb?

that password is the encrypted version of the word “password”.

Forging ahead blindly, I figure that if these tests are failing because
they can’t login, they’re not specifying a password, it might help if I
remove the password. So after removing the passwords from the
database and flushing privileges, I can connect manually to the dbase
without a password, like
$ mysql -u root
or even just
$ mysql

Now, when I run the mysql-ruby test, it works!

$ /usr/local/bin/ruby test.rb localhost root password
Loaded suite test
Started
…FF…
Finished in 0.271991 seconds.

Failure:
test_fetch_double(TC_MysqlStmt2) [test.rb:920]:
<-1.79769313486232e+308> and
<-1.79769313486232e+308> expected to be within
<2.22044604925031e-16> of each other.
Failure:
test_fetch_double_unsigned(TC_MysqlStmt2) [test.rb:937]:
<1.79769313486232e+308> and
<1.79769313486232e+308> expected to be within
<2.22044604925031e-16> of each other.

113 tests, 376 assertions, 2 failures, 0 errors

Only two of the several hundred tests fail, and those two probably
don’t mean anything, I figure.

Alas, I still cannot connect to the database from my mod_ruby script.
My script contains essentially:

<%
require ‘mysql’
dbh = Mysql.real_connect(“localhost”, “root”, “”, “test”)
puts "Server version: " + dbh.get_server_info
%>

The browser shows me the HTTP 500 error page, and my apache log shows
me:

[Mon Jan 01 23:46:01 2007] [error] mod_ruby:
/usr/local/apache2/htdocs/db.rhtml:13:in `real_connect’: Can’t connect
to MySQL server on ‘localhost’ (49) (Mysql::Error)

I suspect that the mysql-ruby plugin is not sending the correct
host/user/password as specified, but I’m really not sure, nor can I
figure out a way to debug this further. Any help you can offer me
would be greatly appreciated.

Thanks,
lethe

unknown · January 2, 2007, 1:09pm

On Jan 2, 2007, at 2:50 AM, [email protected] wrote:

mysql.c:2015: error: ‘ulong’ undeclared (first use in this function)

password: NO)
I can connect manually to the database just fine, and here is my user
4 rows in set (0.00 sec)
$ mysql -u root
Finished in 0.271991 seconds.
<1.79769313486232e+308> expected to be within
<%
to MySQL server on ‘localhost’ (49) (Mysql::Error)

I suspect that the mysql-ruby plugin is not sending the correct
host/user/password as specified, but I’m really not sure, nor can I
figure out a way to debug this further. Any help you can offer me
would be greatly appreciated.

Interestingly enough I have the same problem, but hadn’t noticed
because I don’t usually use mysql passwords on my development machine
(intel macbook). I suspect this is a bug in the mysql gem itself.
It already has to get patched to compile, so there may be other issues.

I’ll look at it some today and see if I can dig up any more details,
but for the moment I can just add a hearty “Me too!”
-Mat

unknown · January 24, 2007, 4:14pm

On Jan 2, 2007, at 2:50 AM, [email protected] wrote:

figure out a way to debug this further. Any help you can offer me
would be greatly appreciated.

Sorry this took me forever to get back to, but I think I may have
stumbled across a fix. Basically the problem seems to surround
mysql’s replacement of a ulong typedef with my_ulonglong instead. No
idea why. Pretty sure it’s something new with MySQL 5, maybe even
just only the OS X distribution.

Anyway, before you compile the gem insert the following at line 108
in mysql.h (probably /usr/local/mysql/include/mysql.h)

#if !defined(HAVE_ULONG) && !defined(TARGET_OS_LINUX) && !defined
(__USE_MISC)
typedef unsigned long ulong; /* Short for unsigned long */
#endif

Then build the gem:
sudo gem install mysql – --with-mysql-dir=/usr/local/mysql # not
sure if that mysql-dir field is necesary, but I did it anyway

Now password authentication is working for me again. I’d also remove
those lines from mysql.h once you’re done. I have no idea what they’d
do when trying to compile other plugins.

I haven’t researched what the exact cause of the problem, but this
seems like a workaround till mysql and the mysql gem get back in sync.

Hope it helps!
-Mat

unknown · January 28, 2007, 11:21pm

On Jan 24, 7:14 am, Mat S. [email protected] wrote:

Anyway, before you compile the gem insert the following at line 108
in mysql.h (probably /usr/local/mysql/include/mysql.h)

#if !defined(HAVE_ULONG) && !defined(TARGET_OS_LINUX) && !defined
(__USE_MISC)
typedef unsigned long ulong; /* Short for unsigned long */
#endif

Alright, I’ve done this step.

Then build the gem:
sudo gem install mysql – --with-mysql-dir=/usr/local/mysql # not
sure if that mysql-dir field is necesary, but I did it anyway

Actually, I’m trying to install directly from the mysql-ruby tarball,
rather than gem. After I run
$ ruby extconf.rb --with-mysql-dir=/usr/local/mysql
$ make
$ ruby test.rb nonexistenthost nonexistentuser stupidpassword

I continue to get errors of the form

Error:
test_sqlstate(TC_MysqlStmt2):
Mysql::Error: Access denied for user ‘lethe’@‘localhost’ (using
password: NO)
test.rb:441:in new' test.rb:441:in setup’

In other words, the test suite is not receiving the hostname and login
that I’m specifying on the command line, rather it’s defaulting to my
userlogin and localhost. Don’t know why.

I try it your way too, though. sudo gem install mysql (the newest
version I can get this way is apparently 2.7, whereas my tarball is
2.7.3). But no difference: I can connect to the database in irb, but
not from a web script. I continue to get the error

[Sun Jan 28 13:55:32 2007] [error] mod_ruby: /usr/local/apache2/htdocs/
eruby/dbtest.rhtml:9:in `real_connect’: Can’t connect to MySQL server
on ‘localhost’ (49) (Mysql::Error)

from apache logs. So real_connect works in irb, but not in a mod_ruby
script. I’m not sure whether that is related to the failure of the
mysql test suite to get the user/pass I specify on the command line.

Now password authentication is working for me again. I’d also remove
those lines from mysql.h once you’re done. I have no idea what they’d
do when trying to compile other plugins.

I haven’t researched what the exact cause of the problem, but this
seems like a workaround till mysql and the mysql gem get back in sync.

Hope it helps!
-Mat

Thanks for your help, Mat. This is pretty frustrating, so it’s nice
to have people try to help. Unfortunately, this doesn’t seem to have
helped me. Maybe our problems are different? Do you have any further
insight to share about that?

unknown · February 6, 2007, 6:06am

On Jan 28, 2:18 pm, “zig” [email protected] wrote:

Thanks for your help, Mat. This is pretty frustrating, so it’s nice
to have people try to help. Unfortunately, this doesn’t seem to have
helped me. Maybe our problems are different? Do you have any further
insight to share about that?

I said that this workaround didn’t fix things for me, but maybe it
did. At this point, I’m a little foggy on which parts worked when,
since I’ve only looked at this sporadically over the course of a
couple of weeks. My test.rb unit testing still does not capture the
login I hand it on the command line; that thing is not working. For a
while, I thought I was still broken. I couldn’t connect to the
database in my rhtml file, so I figured that the problem with my
test.rb meant that the software just isn’t working on my system. Not
so. I did notice that I can connect in irb. In fact, my rhtml test
file will connect to the database if I run eruby on it from the
command line like

eruby db.rhtml

When I discovered this, I realized that I must be closer to working
than I thought. I googled the woefully uninformative error message
from my apache log (and it’s also worth pointing out that you can send
that error right to the browser, rather than fishing it out of the
apache error log, by encapsulating the mysql commands with some
exception catching), that error again was

/usr/local/apache2/htdocs/db.rhtml:13:in `real_connect’: Can’t connect
to MySQL server on ‘localhost’ (49) (Mysql::Error)

Some of the google hits indicated that this error means that the
mysql.sock file was not found. Mysql#real_connect takes a parameter
for the mysql.sock socket file. Specifying this in my rhtml file made
everything work.

In the end, my file looked like this:

Eruby + mysql/ruby

This is a test of the mod_ruby/Eruby mysql/ruby c bindings (not the pure ruby plugin known as ruby/mysql)

<% require 'mysql' begin dbh = Mysql.real_connect("localhost", "root", "password", "test", 3306,'/tmp/mysql.sock') puts "Server version: " + dbh.get_server_info dbh.select_db("db") res = dbh.query("select * from table where id = 1") res.fetch_row().each {|i| puts i} rescue Mysql::Error puts $!.error end

%>

I guess I’m up and running now, so let me give thanks to the newsgroup
for support, and especially to Mat for his help.

And by the way, I don’t remember completely, but I’m pretty sure that
I couldn’t get this far before I implemented Mat’s fix. So I think
that actually was the resolution of my problem, despite what I said
above.

Also, I still don’t know why I have to specify the socket file within
the Apache environment mod_ruby rhtml file, but not when running irb
or eruby from the command line. Obvious some environment variable is
different, which causes the socket file not to be found in the Apache
environment. But which? I would like to figure that out too, it
would be nice not to have to type that in, though it’s not too
important. I played around with the PATH variable, I don’t think
that’s the problem. So feel free to shoot me the answer to that, if
you have it.

Otherwise, thanks again all.

unknown · February 11, 2007, 10:40pm

On Jan 24, 7:14 am, Mat S. [email protected] wrote:

I’d also remove
those lines from mysql.h once you’re done. I have no idea what they’d
do when trying to compile other plugins.

I can confirm that it is indeed necessary to delete those lines after
installing mysql-ruby. php failed to compile with those lines present
in my mysql.h.

unknown · February 6, 2007, 5:35am

On Jan 1, 11:48 pm, [email protected] wrote:

After googling around, I found that this error is known, and can be
fixed by simply declaring that variable in mysql.c. Seehttp://www.maxdunn.com/typo/articles/2006/12/12/installing-mysql-gem-…
orhttp://typo.pburkholder.com/articles/tag/macosx
orhttp://www.planetrubyonrails.org/show/feed/11
for details.

After declaring that variable

For the sake of completeness and self-containedness, let me type in
what the fix was that was linked in those blogs.

To resolve the

mysql.c: In function ‘Init_mysql’:
mysql.c:2015: error: ‘ulong’ undeclared (first use in this function)

error, the workaround to this bug is to add the line

#define ulong unsigned long

to mysql.c near the top with the other preprocessor defs. I can
confirm that this fix enabled me to successfully compile the
software. But see Mat’s post later in this thread for what is
probably a better fix.