Haikus for thought
Posted by Nick Sieger Thu, 18 May 2006 02:48:00 GMT
Open source Java.
Who could possibly fork it
What? Not IBM!
Open source Java
Rather be hacking Ruby
Too late to matter
Open source Java
Need dynamic languages
Use JRuby now
JRuby on Rails and ActiveRecord on JDBC
Posted by Nick Sieger Mon, 15 May 2006 03:12:00 GMT
Tom and Charlie have just experienced what can only be described as a watershed moment in the grand scheme of dynamic languages on the JVM. The Rails experience may soon be visiting a Java application server near you! Even though JRuby will be in perpetual catch-up mode with C Ruby, Tom and Charlie and the rest of the JRuby contributors have shown incredible perseverance in tracking the Ruby language despite the lack of any formal specification. Maybe Rails will never be mainstream, but the possibilities just got a whole lot more interesting. I agree with Obie that this could be a game-changer.
Now, a few comments about the ActiveRecord JDBC adapter. This code can still be considered alpha quality at best. It’s awesome that Tom and Charlie will be able to demo a top-to-bottom, working Rails app on JRuby, but don’t jump to conclusions yet that this will be anything like a write-once, deploy-to-any-database kind of experience. But you didn’t think it would, did you? We all learned that about Java a long time ago, right?
You can check out the code here. At the moment, I’ve only tried it with MySQL. Most of the problems with it come from the lossy mapping from ActiveRecord’s abstraction of the database to JDBC’s. (Although I suspect as more JDBC drivers are tried that there will eventually be compatibility issues with different implementations of the JDBC spec.)
Probably the thorniest issue is the one of type conversion. ActiveRecord has a fairly simple notion of types: :string, :text, :integer, :float, :datetime etc. Compare this to JDBC’s. What a mess! Right now there are arrays of procs for each AR type that try to guess the best JDBC type to use. This will certainly need improvement to become a more robust solution.
Probably the most promising approach may be to create a patch that refactors much of the AR adapters’ type conversion methods into separate modules that could be included into instances of the JDBC adapter depending on the underlying database. Then the JDBC types wouldn’t be needed at all -- the existing AR database metadata could be reused. Presumably this would require some petitioning of the Rails core team to accept the changes even though the changes don’t buy AR itself any additional flexibility.
If you have a chance to try out the code or can think of any additional tricks that would help the ActiveRecord JDBC implementation along, let me know!
