Hacker News Reader

Comment by joevandyk | Hacker News Reader

Biggest things stopping me from using jruby:

1. Incomplete integration with postgresql. The ActiveRecord jdbc adapater doesn't have all the features that the standard pg adapter does.

2. Slow startup / test runs. At one point, loading large amounts of files (like during rails bootup) was much slower on jruby than MRI.

View on HN

> Slow startup / test runs. At one point, loading large amounts of files (like during rails bootup) was much slower on jruby than MRI.

You can develop on MRI and deploy on JRuby. Several people, including myself and Square, develop JRuby applications this way, and validate stability across multiple Rubies by doing matrix builds on a CI system.

Check out Xavier Shay's talk on the matter:

http://www.youtube.com/watch?v=hMpd4CzR1f8&t=16m

I know several people balk at this suggestion and claim development should be as close as possible to production... and do that despite the fact they develop on OS X and deploy on Linux, develop with a case insensitive filesystem and deploy to a case sensitive filesystem, develop in an environment without load and deploy to an environment with load, etc...

There is good reason to use the same environment. No one wants to be dealing with wacky version issues on remote servers, which is precisely what you would be signing up for.

If you are smart, you'll run CI on JRuby. Then your test environment matches production.

Then I assume your development workstation is an exact duplicate of a production server, and is serving a production load?

Even getting a staging environment to realistically resemble production is an incredibly difficult undertaking. Your development environment is a joke, sorry. If you're expecting it to resemble production in any way, I don't know what else to say except you're extremely confused about how a production environment actually works, or your production environment is a pathetic joke which serves a nonexistent userbase.

Based on this comment, I started looking into JRuby support for the pg gem. I think it's possible; I have started stubbing it out, and the Postgresl JDBC driver publishes additional interfaces that provide everything folks here have been asking for.

I'm looking for help filling it out. Here's the mostly stubbed extension:

https://github.com/headius/jruby-pg

And here's the docs for pgsql's hidden interfaces (cast the JDBC objects to these, and you're good to go):

http://jdbc.postgresql.org/documentation/publicapi/index.htm...

Great news, would be a welcome addition to JRuby!

Interested to do some testing as it comes together and see what I can help with.

This would be brilliant, as Postgres is one of the most commonly used databases with Rails (generally, and also because of Heroku) so having feature parity between the pg gem and JDBC drivers that you can use with, for example, Torquebox would be great, especially for people wanting to migrate to JRuby.

I did some basic benchmarking with one of the JRuby 1.7 preview releases and was impressed enough with the speed benefits to want to try it out with a small app on Torquebox when JRuby 1.7 was released.

Thanks to joevandyk and xiljin for pointing out the search_path and datatype support situation before I undoubtedly encountered them myself - and love the fact that headius has immediately leapt in to try and fix things :-)

May be it would be better to reimplement protocol, like postgres-pr does but using java ? Protocol is rather simple, and postgres-pr could be used as a reference (it implements meaningfull subset).

I use it with Heroku's pg service via a JDBC driver, and I've never had a problem. Do you have any links? Can you elaborate?

Arrays, hstore, domains, etc. Not supported by the activerecord-jdbc-postgresql adapter.

> Incomplete integration with postgresql.

I'm planning on using it with postgresql - do you have any links to whats not supported with the JDBC drivers ?

One of the issues I ran into when looking to migrate a multi-tenant Rails app to Torquebox was lack of schema support (eg. schema_search_path). I was able to workaround those issues using raw sql though.

The JDBC driver doesn't support EXPLAIN or COPY

Reply on news.ycombinator.com