5 ms·

Biggest things stopping me from using jruby: 1. Incomplete integration with postgresql. The ActiveRecord jdbc adapater doesn't have all the features that the s

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.

sheff 14y ago
> 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 ?
- xiljin 14y ago
  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.
- bryanl 14y ago
  The JDBC driver doesn't support EXPLAIN or COPY
jonstokes 14y ago
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?
- joevandyk 14y ago
  Arrays, hstore, domains, etc. Not supported by the activerecord-jdbc-postgresql adapter.
bascule 14y ago
> 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 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...
- nahname 14y ago
  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.
  - headius 14y ago
    If you are smart, you'll run CI on JRuby. Then your test environment matches production.
  - bascule 14y ago
    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.
headius 14y ago
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 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.html http://jdbc.postgresql.org/documentation/publicapi/index.htm...
- wolfeidau 14y ago
  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.
- sheff 14y ago
  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 :-)
- funny_falcon 14y ago
  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).

sheff 14y ago

> 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 ?

xiljin 14y ago
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.
bryanl 14y ago
The JDBC driver doesn't support EXPLAIN or COPY

jonstokes 14y ago

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?

joevandyk 14y ago
Arrays, hstore, domains, etc. Not supported by the activerecord-jdbc-postgresql adapter.

bascule 14y ago

> 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 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...

nahname 14y ago
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.
- headius 14y ago
  If you are smart, you'll run CI on JRuby. Then your test environment matches production.
- bascule 14y ago
  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.

headius 14y ago

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 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.html http://jdbc.postgresql.org/documentation/publicapi/index.htm...

wolfeidau 14y ago
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.
sheff 14y ago
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 :-)
funny_falcon 14y ago
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).