Fails to load in Ruby1.9

[ibc]

I've ruby1.8.7 and 1.9.1 installed. In both I've the gems:

• mysql (2.8.1)
• mysqlplus (0.1.1)

When I require mysqlplus in 1.8 it is correctly loaded. However in Ruby 1.9 I get this error:

LoadError: error loading mysqlplus--this may mean you ran a require
'mysql' before a require 'mysqplus', which much come first

[ibc]

I've found the issue. In gems/mysqlplus-0.1.1/lib/mysqlplus.rb the first line is:

require 'mysql'

This is supposed to load "mysql.so" file in same directory (and it does it in Ruby1.8). but in ruby 1.9 it takes the "normal" mysql gem.

A workaround would be changing the first line with:

require 'mysql.so'

However it seems a bad workaround. A better approach would be ensuring to load the library in the current directory (using FILE and so).

[ibc]

A better aproach:

require File.join(File.dirname(__FILE__), "mysql")

[ibc]

The problem is that after these two solutions, a new call to "require 'mysql'" would load the "normal" mysql gem! ("require" wouldn't return false) so the class would be replaced by the "normal" one!

IMHO mysqlplus should not contain a class called "Mysql" and instead use "MysqlPlus". Other libraries using MySQL could just do:

require "mysqlplus"
Mysql = MysqlPlus

so they could use the usual "Mysql" class as usually.

[rdp]

hmm. Yeah the original thought was to have a fork of "mysql" and submit patches back upstream, so we wanted to stay close to the core. unfortunately the core never accepts patches, so maybe it would be better to head off in that direction.

Is it true that if you do a require File.join(File.dirname(FILE), "mysql") then so a require 'mysql' it will load the old mysql.so? -r

[ibc]

Yes, original "mysql" Mysql replaces "mysqlplus" one: http://gist.github.com/259099 As you can see "require 'mysql'" returns 'true'.

Also you check it with this script I've code: http://gist.github.com/259102 (read the comments to understand how to run it and check the bug)

[ibc]

Hi, is there news about this issue? IMHO the simplest solution would be renaming "mysql.so" to "mysqlplus.so" and in lib/mysqlplus.rb:

require File.join(File.dirname(__FILE__), "mysqlplus")

And then, users or applications must decide to use "mysql" or "mysqlplus".

[rdp]

the kicker is that deep in the gute of rails it may have a line like

require 'mysql'

which will now fail [or override mysqlplus]...

I'm almost tempted to leave it as is and tell users "you MUST uninstall the mysql gem or it will conflict" thoughts? -r

[ibc]

Humm, anyhow I see no reason to keep "mysql.so" under GEMS/mysqlplus/lib/ instead of calling it just "mysqlplus_ext.so" (or whatever).

The line "require 'mysql'" in GEMS/mysqlplus/lib/mysqlplus.rb would behave randomly under Ruby1.9. IMHO depending on how the LAOD_PATH looks it could load the pure Ruby mysql driver rather than "mysql.so" present in same directory.

I agree with your comment, but nothing changes if you rename "mysql.so" to "mysqlplus_ext.so" and change the line "require 'mysql'" with "require 'mysqlplus_ext'". In fact it avoids random conflicts depending on LOAD_PATH.

[rdp]

maybe we can have a fake empty mysql.rb file in there that just does a 'require mysqlplus'

then when rails does a require 'mysql' it'll still work and if people notice all sorts of warnings [which imply that both gems' mysql.so are getting loaded] they can manually uninstall the other gem ?

[ibc]

It's a good idea. However then "mysql.so" should be renamed to any other anme (as "mysqplus_ext.so").

[rdp]

I'm beginning to like the idea :) -r

[skiz]

+1 for using a different class name