jpa57
jpa57

Reputation: 11

Rails 5 does not reference a modified ActiveRecord-jdbc-adapter

problem overview

I have a client with an App I'm trying to get to Rails 5. Historically we modified the activerecord-jdbc-adapter to access a Progress OpenEdge database, and it's been working since Rails 3.2. Currently, I can create a new activerecord-jdbc-adapter gem (v 52.8.xxx) and bundle it with Rails 5.2.8.1, but the error messages I get indicates that it is not using the src/java/arjdbc/jdbc/RubyJdbcConnection.java that I've modified. Looking at the Rails 5 repository, the Gemfile at the root includes the activerecord-jdbcxxxx-adapters for platform Jruby, which should also pull in the generic adapter. My theory is that despite bundling in my custom adapter, it's using code that is included with the various active* and action* gems that make up Rails 5.

I guess I'm hoping I'm wrong and someone can tell me I missed something basic. Otherwise I'm inclined to switch to ODBC and drop Jruby, which is a change I'm not loving.

steps to demonstrate the issue:

in activerecord-jdbc-adapter clone, check out 52-stable

Modify RubyJdbcConnection.java -- add a bunch of comments just to make it different

rake adapters:build

in rails 5.2 app repo, using 'jdbc' as adapter in database.yml

Gemfile

gem 'rails', '~> 5.2'
gem 'activerecord', '~> 5.2'
gem 'activerecord-jdbc-adapter', '= 52.8.xxxxx', :platform => :jruby

commands

bundle install
RAILS_ENV=test rails c
MyModel.first # Model that is backed by the jdbc database

Because the adapter has not been modified to support the OpenEdge database, it fails.
The line number in RubyJdbcConnection matches unmodified source, not the file we modified above.

Upvotes: 0

Views: 36

Answers (1)

jpa57
jpa57

Reputation: 11

This was totally under our control. Some time ago we added some custom Java code and put it in a jar that was loaded via application.rb. It was supposed to only contain the code we needed but inadvertently contained the compiled class file for RubyJdbcConnection.java. I was able to find it by extracting the jar file and looking at the class files. One more reason not to do it this way; our current approach uses a custom gem installed in a Sonatype Nexus repo, so this should not happen again if we just follow the current practice.

Upvotes: 0

Related Questions