I am writing a rails app to connect to an existing Oracle database (out of my control).

I have two example tables I am connecting to, one which works fine under all conditions, and one (Program) which works fine if I type "Program" (with the result being a list of all the columns in the table), and breaks if I type "Program.all" or "Program.first" or seemingly anything that would actually get me data, with the error of:

"ActiveRecord::StatementInvalid: ActiveRecord::JDBCError: No message available: SELECT program.* FROM program"

After extensively trying to figure out the difference between the first (working) table and the Program table, I realized that only the second table has a column of XMLTYPE. Not only that, when I type "Program" in the irb, I see that the same column in Rails is of type nil. (And is the only column in either table that rails thinks is nill).

On advice, I ran the program:

begin
ActiveRecord::Base.connection.execute "SELECT program.* FROM program"
rescue ActiveRecord::JDBCError => e
$stderr.puts e.to_s, *e.backtrace
e.sql_exception.print_stack_trace
end

Which resulted in the error message of:

jruby-1.5.6 :036 > begin
jruby-1.5.6 :037 > ActiveRecord::Base.connection.execute "SELECT PROGRAM.* FROM PROGRAM"
jruby-1.5.6 :038?> rescue ActiveRecord::JDBCError => e
jruby-1.5.6 :039?> $stderr.puts e.to_s, e.backtrace
jruby-1.5.6 :040?> e.sql_exception.print_stack_trace
jruby-1.5.6 :041?> end
ActiveRecord::StatementInvalid: ActiveRecord::JDBCError: No message available: SELECT PROGRAM. FROM PROGRAM
from /home/jenny/.rvm/gems/jruby-1.5.6/gems/activerecord-3.0.3/lib/active_record/connection_adapters/abstract_adapter.rb:202:in log' from /home/jenny/.rvm/gems/jruby-1.5.6/gems/activerecord-jdbc-adapter-1.1.1/lib/arjdbc/jdbc/adapter.rb:183:inexecute'
from (irb):37

Which isn't exactly clarifying things for me.

Is this a bug in the adapter? SHOULD it work with XMLTYPES?

-Jenny

I'm not sure if this is postgres specific, but that is the DB we're using.

We have a table's column in a migration defined as:

t.column "progress", :integer, :default => -1

which worked fine on MRI ruby but does not with arjdbc. The jdbc adapter is convinced the default is nil such in db/schema.rb and creation of new records give them a nil value. I verified that I can successfully set the default value to any value 0 or greater no problem.

Using pgadmin, I can see that the actual properties of the column in the database are fine.

I haven't dug into this one too much. I can get around by making sure to specify -1 as the value of the "progress" column everytime I create a record, but it would be nice to have this one fixed.

Jeff

In Rails 3.1 the Oracle adapter seems to be using the standard Arel::Visitors::ToSql visit_Arel_Nodes_Limit rather than Arel::Visitors::Oracle visit_Arel_Nodes_Limit. It I'm not following it correctly it seems to be using LIMIT rather than ROWNUM at any rate.

I had originally posted this to rails, but we think the issue is here:

jruby-1.6.3
oracle
rails-3.0.8
activerecord-jdbc-adapter-1.1.2.1

At this point I'm not sure where the problem lies so I'm documenting it here - might be a bug in activerecord, arel, or the activerecord-jdbc-adapter.

Our app has a model with no primary key column (e.g. id). When trying to create a record, I get the following error:

Thing.create!
NoMethodError: undefined method `name' for nil:NilClass
    from org/jruby/RubyKernel.java:238:in `method_missing'
    from /Users/dchelimsky/.rvm/gems/jruby-1.6.3@vera/gems/activesupport-3.0.8/lib/active_support/whiny_nil.rb:48:in `method_missing'
    from /Users/dchelimsky/.rvm/gems/jruby-1.6.3@vera/gems/arel-2.0.10/lib/arel/visitors/to_sql.rb:56:in `visit_Arel_Nodes_InsertStatement'
    from org/jruby/RubyArray.java:2336:in `collect'
    from /Users/dchelimsky/.rvm/gems/jruby-1.6.3@vera/gems/arel-2.0.10/lib/arel/visitors/to_sql.rb:55:in `visit_Arel_Nodes_InsertStatement'
    from org/jruby/RubyKernel.java:2096:in `send'
    from /Users/dchelimsky/.rvm/gems/jruby-1.6.3@vera/gems/arel-2.0.10/lib/arel/visitors/visitor.rb:15:in `visit'
    from /Users/dchelimsky/.rvm/gems/jruby-1.6.3@vera/gems/arel-2.0.10/lib/arel/visitors/visitor.rb:5:in `accept'
    from /Users/dchelimsky/.rvm/gems/jruby-1.6.3@vera/gems/arel-2.0.10/lib/arel/visitors/to_sql.rb:18:in `accept'
    from /Users/dchelimsky/.rvm/gems/jruby-1.6.3@vera/gems/activerecord-3.0.8/lib/active_record/connection_adapters/abstract/connection_pool.rb:111:in `with_connection'
    from /Users/dchelimsky/.rvm/gems/jruby-1.6.3@vera/gems/arel-2.0.10/lib/arel/visitors/to_sql.rb:16:in `accept'
    from /Users/dchelimsky/.rvm/gems/jruby-1.6.3@vera/gems/arel-2.0.10/lib/arel/tree_manager.rb:20:in `to_sql'
    from /Users/dchelimsky/.rvm/gems/jruby-1.6.3@vera/gems/arel-2.0.10/lib/arel/select_manager.rb:217:in `insert'
    from org/jruby/RubyKernel.java:2096:in `send'
    from /Users/dchelimsky/.rvm/gems/jruby-1.6.3@vera/gems/activerecord-3.0.8/lib/active_record/relation.rb:14:in `insert'
    from /Users/dchelimsky/.rvm/gems/jruby-1.6.3@vera/gems/activerecord-3.0.8/lib/active_record/persistence.rb:274:in `create'
... 19 levels...
    from org/jruby/RubyKernel.java:1088:in `eval'
    from /Users/dchelimsky/.rvm/gems/jruby-1.6.3@vera/gems/ruby-debug-0.10.4/cli/ruby-debug/commands/irb.rb:99:in `evaluate'
    from /Users/dchelimsky/.rvm/rubies/jruby-1.6.3/lib/ruby/1.8/irb.rb:158:in `eval_input'
    from /Users/dchelimsky/.rvm/rubies/jruby-1.6.3/lib/ruby/1.8/irb.rb:271:in `signal_status'
    from /Users/dchelimsky/.rvm/rubies/jruby-1.6.3/lib/ruby/1.8/irb.rb:155:in `eval_input'
    from org/jruby/RubyKernel.java:1419:in `loop'
    from org/jruby/RubyKernel.java:1191:in `catch'
    from /Users/dchelimsky/.rvm/rubies/jruby-1.6.3/lib/ruby/1.8/irb.rb:154:in `eval_input'
    from /Users/dchelimsky/.rvm/rubies/jruby-1.6.3/lib/ruby/1.8/irb.rb:71:in `start'
    from org/jruby/RubyKernel.java:1191:in `catch'
    from /Users/dchelimsky/.rvm/rubies/jruby-1.6.3/lib/ruby/1.8/irb.rb:70:in `start'
    from /Users/dchelimsky/.rvm/gems/jruby-1.6.3@vera/gems/railties-3.0.8/lib/rails/commands/console.rb:44:in `start'
    from /Users/dchelimsky/.rvm/gems/jruby-1.6.3@vera/gems/railties-3.0.8/lib/rails/commands/console.rb:8:in `start'
    from /Users/dchelimsky/.rvm/gems/jruby-1.6.3@vera/gems/railties-3.0.8/lib/rails/commands.rb:23:in `(root)'
    from org/jruby/RubyKernel.java:1038:in `require'
    from script/rails:6:in `(root)'jruby-1.6.3

To reproduce:

rails new example
cd example
rails g model things name:string

Update the migration to exclude an id column:

class CreateThings < ActiveRecord::Migration
  def self.up
    create_table :things, :id => false do |t|
      t.string :name

      t.timestamps
    end
  end

  def self.down
    drop_table :things
  end
end

Back to the shell:

rake db:migrate
rails runner "Thing.create"

These gems require themselves in their gemspec files to get the version information:

• jdbc-derby
• jdbc-h2
• jdbc-hsqldb
• jdbc-jtds
• jdbc-mysql
• jdbc-postgres
• jdbc-SQLite3

See example at https://github.com/nicksieger/activerecord-jdbc-adapter/blob/master/jdbc-derby/jdbc-derby.gemspec#L4

Since bundler seems to load the gemspec files regardless of platform, this leads to "only for use with JRuby" warnings when running a jruby/mri project on MRI.

We could probably move the version information to a separate file and avoid this warning.

Unfortunately I'm not an expert in this field but I manage to solve that problem by changing 2 files :

1° create lib/arel/visitors/firebird.sql

require 'arel/visitors/compat'

module Arel
module Visitors
class Firebird < Arel::Visitors::ToSql
  def visit_Arel_Nodes_SelectStatement o
    [
     o.cores.map { |x| visit_Arel_Nodes_SelectCore x }.join,
     ("ORDER BY #{o.orders.map { |x| visit x }.join(', ')}" unless o.orders.empty?),
     ("ROWS #{limit_for(o.limit)} " if o.limit),
     ("TO #{o.offset} " if o.offset),
    ].compact.join ' '
  end

end
end
end

and add this methid in lib/arjdbc/firebird/adapter.rb

def arel2_visitors
  require 'arel/visitors/firebird'
  {'firebird' => ::Arel::Visitors::Firebird, 'firebirdsql' => ::Arel::Visitors::Firebird}
end

I'm really really not comfortable with all the Arel / AR stuff but I hope it can help.

The ROW keyword of firebird is explained here : http://www.firebirdsql.org/refdocs/langrefupd21-select.html#langrefupd21-select-rows

Running jruby 1.6.2 on ubuntu 11.04 64bit with rails 3.0.9 and sqlite3.

When running rake db:setup I get:

https://gist.github.com/1067648

activerecord-jdbc and rails 3.1 prepare statements seem incompatible

Stack trace:
https://gist.github.com/02a7e417a4d371cd6951

Given my database.yml looks like this:

development:
        adapter: jdbc
        driver: oracle.jdbc.OracleDriver
        url: jdbc:oracle:thin:@SOME IP:1521:IDID
        username: sys as sysdba
        password: oracle

And my user.rb model looks like:

class User < MyAppModel
  set_table_name 'user$'

  attr_accessible :name, :password
end

When I try to see the coluns of the "User" model:

irb(main):004:0> User                                           
ActiveRecord::JDBCError: Table USER$ does not exist
    from arjdbc/jdbc/RubyJdbcConnection.java:121:in `columns'
    from /Users/ened/bin/jruby-1.6.0/lib/ruby/gems/1.8/gems/activerecord-jdbc-adapter-1.1.1/lib/arjdbc/oracle/adapter.rb:337:in `columns'
    from /Users/ened/bin/jruby-1.6.0/lib/ruby/gems/1.8/gems/activerecord-3.0.7/lib/active_record/base.rb:680:in `columns'
    from /Users/ened/bin/jruby-1.6.0/lib/ruby/gems/1.8/gems/activerecord-3.0.7/lib/active_record/base.rb:797:in `inspect'
    from /Users/ened/bin/jruby-1.6.0/lib/ruby/1.8/irb.rb:310:in `output_value'
    from /Users/ened/bin/jruby-1.6.0/lib/ruby/1.8/irb.rb:159:in `eval_input'
    from /Users/ened/bin/jruby-1.6.0/lib/ruby/1.8/irb.rb:271:in `signal_status'
    from /Users/ened/bin/jruby-1.6.0/lib/ruby/1.8/irb.rb:155:in `eval_input'
    from org/jruby/RubyKernel.java:1417:in `loop'
    from org/jruby/RubyKernel.java:1190:in `catch'
    from /Users/ened/bin/jruby-1.6.0/lib/ruby/1.8/irb.rb:154:in `eval_input'
    from /Users/ened/bin/jruby-1.6.0/lib/ruby/1.8/irb.rb:71:in `start'
    from org/jruby/RubyKernel.java:1190:in `catch'
    from /Users/ened/bin/jruby-1.6.0/lib/ruby/1.8/irb.rb:70:in `start'
    from /Users/ened/bin/jruby-1.6.0/lib/ruby/gems/1.8/gems/railties-3.0.7/lib/rails/commands/console.rb:44:in `start'
    from /Users/ened/bin/jruby-1.6.0/lib/ruby/gems/1.8/gems/railties-3.0.7/lib/rails/commands/console.rb:8:in `start'
    from /Users/ened/bin/jruby-1.6.0/lib/ruby/gems/1.8/gems/railties-3.0.7/lib/rails/commands.rb:23:in `(root)'
    from org/jruby/RubyKernel.java:1037:in `require'

And the same if I change "set_table_name" to "all_users".

But when I try to issue statements:

irb(main):005:0> User.connection.execute 'select user from dual'
=> [{"user"=>"SYS"}]

irb(main):006:0> User.connection.execute 'select count(*) from all_users'
=> [{"count(*)"=>"38"}]

So I could see data.

Are there any known problems with Oracle and or these special tables?

Thanks a lot,
Sebastian

When the JNDI name is wrong, in the method def adapter_spec(config) the line conn = Java::javax.naming.InitialContext.new.lookup(config[:jndi]).getConnection will throw a javax.naming.NamingException, then rescue with a conn.close will fail with NoMethodError (undefined method 'close' for nil:NilClass) because the conn object is nil.
The problem is that the error is not explicit, so you have to look at the activerecord-jdbc-adapter source code to realize that the JNDI name was not found.

I tend to use UUID and Geometric column types on Postgres, which work fine under MRI ActiveRecord, as they just get mapped to their string representations; so,

model.columns_hash['uuid_column'].type
=> 'string'

Under AR-JDBC:

model.columns_hash['uuid_column'].type
=> nil

Is this behavior intentional?

Starting Rails 3.0.7 validates_uniqueness_of is optimizing query size by adding .select(1) into the arel query expression. Apparently it produces an invalid SQL for MSSQL:

    Facet.where(:src_ref => '7').limit(1).select(1)

generates

    SELECT t.* FROM 
        (SELECT ROW_NUMBER() OVER(ORDER BY ht_facets.id) AS _row_num, 1 
                 FROM ht_facets WHERE (ht_facets.[src_ref] = N'7')) 
        AS t WHERE t._row_num BETWEEN 1 AND 1

which fails with No column was specified for column 2 of 't'

With regular mysql driver you can fetch values from a row returned from ActiveRecord::Base.connection.execute based on the position of the column in the result set.

Some libraries, like redhillonrails_core use this, and it would be good if the mysql adapter of arjdbc also supported this.

I am not sure this is standard AR functionality.

When creating a column of type :decimal without specifying scale or precision, the scale defaults to 0 and the fractional part of the number is lost. The value is loaded as Fixnum.

Retrieving the same database value with mri ruby and the postgresql adapter behaves as expected: the value is loaded as BigDecimal and still contains the fractional part.

I created a failing test case: til@c72b59d

I use the jdbc initializer (require "arjdbc" in config/initializers/jdbc.rb). After upgrading to Rails 3.1 and using activerecord-jdbc-adapter from master (21e7049), it no longer works:

RuntimeError: Please install the sqlite3 adapter: `gem install activerecord-sqlite3-adapter` (sqlite3 is not part of the bundle. Add it to Gemfile.)

The problem is that the initializer is executed too late (when activerecord is already loading database stuff).

It can be fixed by requiring arjdbc early in config/environment.rb though.

NoMethodError: undefined method `first' for #String:0x24748417
replace_limit_offset! at /Users/kim/.rvm/gems/jruby-1.6.2/gems/activerecord-jdbc-adapter-1.1.2/lib/arjdbc/mssql/limit_helpers.rb:72
visit_Arel_Nodes_SelectStatement at /Users/kim/.rvm/gems/jruby-1.6.2/gems/activerecord-jdbc-adapter-1.1.2/lib/arel/visitors/sql_server.rb:31

This is caused by using 'first' instead of '[0]'. There are two occurences at line 72, and line 75.

Be glad to prepare a fork and submit a pull request if you like.

Hello, I'm using jruby 1.6.0, activerecord-jdbc-adapter-1.1.1 and jdbc-postgres-9.0.801.
When I do a destroy action I have the strange error message on subject.

The error from a rails console session:

jruby-1.6.3 :001 > reload!; ENV["RAILS_ENV"] = 'development'; ENV['DEBUG'] = 'true'; Sdrv2Pool.all
Reloading...
(4.0ms) SET SQL_AUTO_IS_NULL=0
(4.0ms) SET SQL_AUTO_IS_NULL=0
(0.0ms) SET SQL_AUTO_IS_NULL=0
(0.0ms) SET SQL_AUTO_IS_NULL=0
ArgumentError: wrong number of arguments (3 for 2)
from /Users/charl/.rvm/gems/[email protected]/gems/activerecord-jdbc-adapter-1.1.2/lib/arjdbc/jdbc/adapter.rb:275:in select' from /Users/charl/.rvm/gems/[email protected]/bundler/gems/rails-4c76991120b6/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:9:inselect_all'
from /Users/charl/.rvm/gems/[email protected]/bundler/gems/rails-4c76991120b6/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:62:in select_all' from /Users/charl/.rvm/gems/[email protected]/bundler/gems/rails-4c76991120b6/activerecord/lib/active_record/base.rb:469:infind_by_sql'
from /Users/charl/.rvm/gems/[email protected]/bundler/gems/rails-4c76991120b6/activerecord/lib/active_record/relation.rb:111:in to_a' from /Users/charl/.rvm/gems/[email protected]/bundler/gems/rails-4c76991120b6/activerecord/lib/active_record/relation/finder_methods.rb:155:inall'
from org/jruby/RubyBasicObject.java:1684:in __send__' from /Users/charl/.rvm/gems/[email protected]/bundler/gems/rails-4c76991120b6/activerecord/lib/active_record/base.rb:440:inall'
from (irb):1:in evaluate' from org/jruby/RubyKernel.java:1093:ineval'
from org/jruby/RubyKernel.java:1419:in loop' from org/jruby/RubyKernel.java:1205:incatch'
from org/jruby/RubyKernel.java:1205:in catch' from /Users/charl/.rvm/gems/[email protected]/bundler/gems/rails-4c76991120b6/railties/lib/rails/commands/console.rb:45:instart'
from /Users/charl/.rvm/gems/[email protected]/bundler/gems/rails-4c76991120b6/railties/lib/rails/commands/console.rb:8:in start' from /Users/charl/.rvm/gems/[email protected]/bundler/gems/rails-4c76991120b6/railties/lib/rails/commands.rb:40:in(root)'
from org/jruby/RubyKernel.java:1047:in require' from script/rails:6:in(root)'jruby-1.6.3 :002 >

I have tried this with rails 3.1.0rc1 to 3-1-stable, activerecord-jdbc-adapter v1.1.2.

My model:

require 'active_support'
require 'action_view'

include ActiveSupport
include ActionView::Helpers::TextHelper

class Sdrv2Pool < ActiveRecord::Base
set_table_name :pools
set_primary_key :pool_id

establish_connection "sdrv2_#{ENV["RAILS_ENV"]}"

scope :all_entries, where("sline_id IN (?)", 23).order('pool_shortname ASC')
end

The code mentioned in the error (adapter.rb:275):

274 def select(_args)
275 execute(_args)
276 end

and this leads to (adapter.rb:179):

179 def execute(sql, name = nil)
180 if name == :skip_logging
181 _execute(sql)
182 else
183 log(sql, name) { _execute(sql) }
184 end
185 end

Here is what the 'args' supplied to select from the rails app looks like:

["SELECT pools.* FROM pools ", "Sdrv2Pool Load", []]

So, by the looks of things select is passing an array larger than 2 elements on to execute that is choking on it. I have modified select like this to get it to work for my purposes, for the moment:

274 def select(*args)
275 execute(args[0..1])
276 end

This is a completely naive change with absolutely no guarantees or proper testing.

Discovered an issue when using this outside of Rails i.e managing requires from filesystem rather than gem

File: activerecord-jdbc-adapter / lib / arjdbc / jdbc / discover.rb

files = $LOAD_PATH.map do |p|
        discover = File.join(p, 'arjdbc','discover.rb')
        File.exist?(p) ? discover : nil

I believe Line 8 should read :

File.exist?(discover) ? discover : nil

Otherwise later it attempts to require 'arjdbc','discover.rb' from strange places in LOAD_PATH

Thanks
tom

With jdbc-sqlite3 + Rails 3.1 rc5, I get the error:

ArgumentError: wrong number of arguments (6 for 5)
  /home/vagrant/.rvm/gems/jruby-1.6.3/gems/activerecord-3.1.0.rc5/lib/active_record/relation.rb:70:in `insert'

Please see details at http://travis-ci.org/#!/nahi/paperclip/builds/83481
With Rails 3.0, it's OK.

And I found this gist by googling: https://gist.github.com/969920
He seems to be using PostgreSQL adapter. Something changed in AR 3.1.0?

On destroy I have the message in subject.
I'm using jruby 1.6.0 and activerecord-jdbc-adapter-1.1.1.

I'm not sure why the database I'm using is set up as such, but I have a need to use a schema other than my own in Oracle. I patched it by changing oracle_schema to the following in lib/arjdbc/oracle/adapter.rb:

def oracle_schema
if @config[:schema]
@config[:schema].to_s
elsif @config[:username]
@config[:username].to_s
end
end

and specified schema in data my database.yml. Could this be a feature?

=> jruby-1.6.2 [ darwin-x86_64-java ]

jruby -S rails new bazinga --template http://jruby.org
jruby -S bundle install
jruby -S rails s or jruby -S gem install warbler; jruby -S warble => deploy in jboss 4.2

Error:
LocalJumpError

yield called out of block

When I switch activerecord-jdbc-adapter version to older release like 1.1.1

Everything goes ok

kudos to @abstractj for tracking it down

I'll try to bisect it later, but better keep it here for reference :)

EDIT: DISREGARD AND PLEASE CLOSE, I'm not sure what the deal was but a strange bundler vendor/cache path issue was the problem. Sorry for the issue noise.

I have a simple activerecord model. If the first database request is like:

Post.first

it gets an exception, because the SQL contains a LIMIT clause, which is not existent in Oracle SQL.

If the first database request is like:

Post.all

followed by

Post.first

then no exception is thrown and everything works fine.

The problem can hopefully be reproduced with the attached example code. Activerecord 2.2.2 and 2.3.8 work fine.

require 'rubygems'
gem 'activerecord', '= 3.0.3'
gem 'activerecord-jdbc-adapter', '= 1.1.1'

require 'active_record'

ActiveRecord::Base.establish_connection(
:adapter => 'jdbc',
:driver => 'oracle.jdbc.OracleDriver',
:username => 'drei',
:password => 'drei',
:url => 'jdbc:oracle:thin:@Server-name:1521:db-name')

class Post < ActiveRecord::Base
end

1st run:

puts Post.first.inspect # produces SQL with LIMIT clause, fails

after that, try:

Post.all # works fine
puts Post.first.inspect # produces SQL with ROWNUM clause, works fine

Hello,

if a table does not exists and I use oracle with
rake db:schema:load

I got following error:

 rake aborted!
 ActiveRecord::JDBCError: ORA-00942: table or view does not exist

I fixed this issue for me in lib/arjdbc/oracle/adapter.rb
with following change

 def drop_table(name, options = {}) #:nodoc:
     super(name)
     seq_name = options[:sequence_name] || "#{name}_seq"
    execute "DROP SEQUENCE #{seq_name}" rescue nil
 end

to

   def drop_table(name, options = {}) #:nodoc:
      super(name) rescue nil
      seq_name = options[:sequence_name] || "#{name}_seq"
      execute "DROP SEQUENCE #{seq_name}" rescue nil
   end

Regards
Dieter

The SQLite3 driver is working fine with 1.1.1 but an error occurs when trying to use 1.1.2 and master :

ActiveRecord::JDBCError

The driver encountered an unknown error: java.sql.SQLException: path to 'vfs:/Volumes/Data/Downloads/torquebox-1.1/apps/myapp/db/development.sqlite3': '/Volumes/Data/Downloads/torquebox-1.1/vfs:' does not exist

Call Stack:

vfs:/Volumes/Data/Users/jdmorani/.rvm/gems/jruby-1.6.3/bundler/gems/activerecord-jdbc-adapter-dacc515abe5c/lib/arjdbc/jdbc/connection.rb:91:in initialize' vfs:/Volumes/Data/Users/jdmorani/.rvm/gems/jruby-1.6.3/bundler/gems/activerecord-jdbc-adapter-dacc515abe5c/lib/arjdbc/jdbc/adapter.rb:31:ininitialize'
vfs:/Volumes/Data/Users/jdmorani/.rvm/gems/jruby-1.6.3/bundler/gems/activerecord-jdbc-adapter-dacc515abe5c/lib/arjdbc/jdbc/connection_methods.rb:6:in jdbc_connection' vfs:/Volumes/Data/Users/jdmorani/.rvm/gems/jruby-1.6.3/bundler/gems/activerecord-jdbc-adapter-dacc515abe5c/lib/arjdbc/sqlite3/connection_methods.rb:16:insqlite3_connection'
org/jruby/RubyKernel.java:2096:in send' activerecord (3.1.0.rc4) lib/active_record/connection_adapters/abstract/connection_pool.rb:292:innew_connection'
activerecord (3.1.0.rc4) lib/active_record/connection_adapters/abstract/connection_pool.rb:302:in checkout_new_connection' activerecord (3.1.0.rc4) lib/active_record/connection_adapters/abstract/connection_pool.rb:254:incheckout'
org/jruby/RubyKernel.java:1419:in loop' activerecord (3.1.0.rc4) lib/active_record/connection_adapters/abstract/connection_pool.rb:250:incheckout'
/Volumes/Data/Users/jdmorani/.rvm/rubies/jruby-1.6.3/lib/ruby/1.8/monitor.rb:191:in mon_synchronize' activerecord (3.1.0.rc4) lib/active_record/connection_adapters/abstract/connection_pool.rb:249:incheckout'
activerecord (3.1.0.rc4) lib/active_record/connection_adapters/abstract/connection_pool.rb:151:in connection' activerecord (3.1.0.rc4) lib/active_record/connection_adapters/abstract/connection_pool.rb:388:inretrieve_connection'
activerecord (3.1.0.rc4) lib/active_record/connection_adapters/abstract/connection_specification.rb:107:in retrieve_connection' activerecord (3.1.0.rc4) lib/active_record/connection_adapters/abstract/connection_specification.rb:89:inconnection'
activerecord (3.1.0.rc4) lib/active_record/query_cache.rb:51:in call' activerecord (3.1.0.rc4) lib/active_record/connection_adapters/abstract/connection_pool.rb:448:incall'
actionpack (3.1.0.rc4) lib/action_dispatch/middleware/callbacks.rb:29:in call' activesupport (3.1.0.rc4) lib/active_support/callbacks.rb:407:in_run_call_callbacks'
org/jruby/RubyKernel.java:2092:in send' activesupport (3.1.0.rc4) lib/active_support/callbacks.rb:81:inrun_callbacks'
actionpack (3.1.0.rc4) lib/action_dispatch/middleware/callbacks.rb:28:in call' actionpack (3.1.0.rc4) lib/action_dispatch/middleware/reloader.rb:68:incall'
rack (1.3.1) lib/rack/sendfile.rb:101:in call' actionpack (3.1.0.rc4) lib/action_dispatch/middleware/remote_ip.rb:48:incall'
actionpack (3.1.0.rc4) lib/action_dispatch/middleware/show_exceptions.rb:47:in call' railties (3.1.0.rc4) lib/rails/rack/logger.rb:13:incall'
rack (1.3.1) lib/rack/methodoverride.rb:24:in call' rack (1.3.1) lib/rack/runtime.rb:17:incall'
activesupport (3.1.0.rc4) lib/active_support/cache/strategy/local_cache.rb:72:in call' rack (1.3.1) lib/rack/lock.rb:15:incall'
actionpack (3.1.0.rc4) lib/action_dispatch/middleware/static.rb:53:in call' railties (3.1.0.rc4) lib/rails/engine.rb:438:incall'
org/jruby/RubyKernel.java:2096:in send' railties (3.1.0.rc4) lib/rails/railtie/configurable.rb:30:inmethod_missing'

Hey Nick-

With the way the code is currently laid out, you can't really bundle any of the adapters. There's a few things that contribute to this, and I'd like some feedback before I work up some sort of pull request:

The issues

1. The adapters themselves require the exact version of the main library. This means that I can't just bundle edge of activerecord-jdbc-adapter, I also have to bundle edge activerecord-jdbcpostgresql-adapter too. This could be fixed by relaxing this to ~>1.1.2.

2. It's impossible to tell bundler to use the edge adapters from a git repository. This is because bundler expects sub-gems to be in a directory with their name, right under top level, like Rails does. I made a tiny commit on my fork, but this doesn't take into account any of the Rakefiles, etc. But it does let you bundle properly, with

   git "https://github.com/steveklabnik/activerecord-jdbc-adapter.git" do
   gem "activerecord-jdbc-adapter", :ref => "whatever"
   gem "activerecord-jdbcpostgresql-adapter"
   end

Which is cool! But this leads to problem #3:

1. Because you're using hoe, I think, the built jar and the Mainfest.txt are in .gitignore. This leads to messages like

   Using activerecord-jdbc-adapter (1.1.1) from git://github.com/steveklabnik/activerecord-jdbc-adapter.git (at master)
   activerecord-jdbc-adapter at blahblahblah did not have a valid gemspec.
   This prevents bundler from installing bins or native extensions, but that may not affect its functionality.
   The validation message from Rubygems was:
   ["Manifest.txt", "lib/arjdbc/jdbc/adapter_java.jar"] are not files

Then, it doesn't actually work, and gives you

no such file to load -- arjdbc/jdbc/adapter_java

which is expected.

Now, I'm not sure if this is fix-able. It makes sense that binaries aren't kept in git, but is there a way we can get Bundler to generate them?

What I had to do

To get it to work, I ended up pulling down my fork, shoving it in vendor/gems, and removing the .git folder from the directory, and then committing it all in my app. I know that some people 'Vendor Everything,' but that really bothers me... Point is, this isn't so much an urgent thing as a "I thought I'd let you know about it" thing.

In conclusion

I'd love to hear some feedback about this problem, and if there's anything that can be done to fix it. I do think that moving the adapters out to the top level would be nice, but it's your project, you can organize it as you wish. If that interests you, I'd be willing to work up a patch to change all the paths in all the support files.

I'm using ARJDBC to connect to an AS/400. Once every while, maybe once in every 100000 executions, a query fails due to a quoting issue. As an example:

[2011-03-22 15:54:11] DEBUG ActiveRecord::Base: ActiveRecord::JDBCError: [SQL0206]
Column NP0001 not in specified tables.: SELECT  cps.* FROM cps WHERE cps.c
omm_produkt_code = NP0001 ORDER BY cps.id DESC FETCH FIRST ROW ONLY

In this query, the NP0001 should have been quoted. This query is the result of the code:
CPS.where('comm_produkt_code' => some_variable)
The 'some_variable' always contains a String. If I run the exact same code again, immediately after such a failure, it succeeds, as it usually does. When I run the code again, the inputs, database and resulting paths through the code are exactly the same: there is no possibility that 'some_variable' is a String containing 'NP0001' sometimes, and some other datatype whose to_s results in 'NP0001' at other times. There are other queries, like
XYZ.find(some_string_id)
that fail in the same way, even though the input strings in those cases are literally constructed using a "foo #{bar} baz" construction, which couldn't possibly yield anything other than a string.

As a result, I'm guessing it must be a concurrency issue. That would explain the Schrodinger-nature of the issue and is somewhat suggested by the fact that I've only seen it happen when multiple threads were executing queries against the database and never during singlethreaded executions. Unfortunately, I haven't been able to reproduce the behaviour in a selfcontained piece of code that I could post here. From reading through the Arel and ARJDBC code, I haven't been able to discover any possibly threading issues, but I'm hoping this report causes someone else to go "Ah, yes, there is an issue there-and-there".

There are some issues related to LEFT OUTER JOIN in sqlite3 3.6.14.2 v056. This affect Redmine (see http://www.redmine.org/issues/2019) issue queries (and probably many Rails applications with complex queries).

sqlite3 3.6.23.1 (v057) fixes these issue and works properly with Redmine. This version is not yet available on http://www.zentus.com/sqlitejdbc/ but a user build it (https://lists.hcoop.net/pipermail/sqlitejdbc/2010-August/000061.html).

I've tested it with Redmine and it works nice.

Hey there.

I'm experiencing the following error with JRuby 1.6.4 and Rails 3.1.0 with activerecord-jdbcsqlite3-adapter.

root@trinidad:~/sample-app# rake db:migrate RACK_ENV=production --trace
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Invoke db:load_config (first_time)
** Invoke rails_env (first_time)
** Execute rails_env
** Execute db:load_config
** Execute db:migrate
==  CreateUsers: migrating ====================================================
-- create_table(:users)
   -> 0.0040s
   -> 0 rows
==  CreateUsers: migrated (0.0050s) ===========================================

rake aborted!
An error has occurred, this and all later migrations canceled:

(TypeError) can't convert Arel::InsertManager into String
arjdbc/jdbc/RubyJdbcConnection.java:317:in `execute_update'
/usr/local/rvm/gems/jruby-1.6.4/gems/activerecord-jdbc-adapter-1.1.3/lib/arjdbc/sqlite3/adapter.rb:149:in `insert_sql'
/usr/local/rvm/gems/jruby-1.6.4/gems/activerecord-jdbc-adapter-1.1.3/lib/arjdbc/jdbc/adapter.rb:195:in `jdbc_insert'
/usr/local/rvm/gems/jruby-1.6.4/gems/activerecord-3.1.0/lib/active_record/migration.rb:727:in `record_version_state_after_migrating'
/usr/local/rvm/gems/jruby-1.6.4/gems/activerecord-3.1.0/lib/active_record/migration.rb:688:in `migrate'
org/jruby/RubyProc.java:274:in `call'
org/jruby/RubyProc.java:229:in `call'
/usr/local/rvm/gems/jruby-1.6.4/gems/activerecord-3.1.0/lib/active_record/migration.rb:742:in `ddl_transaction'
/usr/local/rvm/gems/jruby-1.6.4/gems/activerecord-3.1.0/lib/active_record/connection_adapters/abstract/database_statements.rb:192:in `transaction'
/usr/local/rvm/gems/jruby-1.6.4/gems/activerecord-3.1.0/lib/active_record/transactions.rb:208:in `transaction'
/usr/local/rvm/gems/jruby-1.6.4/gems/activerecord-3.1.0/lib/active_record/migration.rb:742:in `ddl_transaction'
/usr/local/rvm/gems/jruby-1.6.4/gems/activerecord-3.1.0/lib/active_record/migration.rb:686:in `migrate'
org/jruby/RubyArray.java:1603:in `each'
/usr/local/rvm/gems/jruby-1.6.4/gems/activerecord-3.1.0/lib/active_record/migration.rb:671:in `migrate'
/usr/local/rvm/gems/jruby-1.6.4/gems/activerecord-3.1.0/lib/active_record/migration.rb:549:in `up'
/usr/local/rvm/gems/jruby-1.6.4/gems/activerecord-3.1.0/lib/active_record/migration.rb:530:in `migrate'
/usr/local/rvm/gems/jruby-1.6.4/gems/activerecord-3.1.0/lib/active_record/railties/databases.rake:161:in `(root)'
org/jruby/RubyProc.java:274:in `call'
org/jruby/RubyProc.java:229:in `call'
/usr/local/rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/task.rb:205:in `execute'
org/jruby/RubyArray.java:1603:in `each'
/usr/local/rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/task.rb:200:in `execute'
/usr/local/rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/task.rb:158:in `invoke_with_call_chain'
/usr/local/rvm/rubies/jruby-1.6.4/lib/ruby/1.8/monitor.rb:191:in `mon_synchronize'
/usr/local/rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/task.rb:151:in `invoke_with_call_chain'
/usr/local/rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/task.rb:144:in `invoke'
/usr/local/rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/application.rb:112:in `invoke_task'
/usr/local/rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/application.rb:90:in `top_level'
org/jruby/RubyArray.java:1603:in `each'
/usr/local/rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/application.rb:90:in `top_level'
/usr/local/rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/application.rb:129:in `standard_exception_handling'
/usr/local/rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/application.rb:84:in `top_level'
/usr/local/rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/application.rb:62:in `run'
/usr/local/rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/application.rb:129:in `standard_exception_handling'
/usr/local/rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/application.rb:59:in `run'
/usr/local/rvm/gems/jruby-1.6.4/gems/rake-0.9.2/bin/rake:32:in `(root)'
org/jruby/RubyKernel.java:1063:in `load'
/usr/local/rvm/gems/jruby-1.6.4/bin/rake:19:in `(root)'
Tasks: TOP => db:migrate
root@trinidad:~/sample-app# 

This is just a freshly generated Rails 3.1 app as I was experimenting with JRuby to see if I would use it for my next project. Unfortunately I wasn't able to understand why this exception kept being raised. I don't experience this error when running on Rails 3.0.0.

My Gemfile:

gem 'rails', '3.1.0'
gem 'activerecord-jdbcsqlite3-adapter'
gem 'jruby-openssl'
gem 'json'

group :assets do
  gem 'sass-rails', "  ~> 3.1.0"
  gem 'coffee-rails', "~> 3.1.0"
  gem 'uglifier'
  gem 'therubyrhino'
end

gem 'jquery-rails'
gem 'trinidad'

And my database.yml

development:
  adapter: jdbcsqlite3
  database: db/development.sqlite3
test:
  adapter: jdbcsqlite3
  database: db/test.sqlite3
production:
  adapter: jdbcsqlite3
  database: db/production.sqlite3

Migration file:

class CreateUsers < ActiveRecord::Migration
  def change
    create_table :users do |t|
      t.string :name

      t.timestamps
    end
  end
end

Any idea why I'm getting these errors?

Cheers,
Michael

I filed this issue here as well:

http://jira.codehaus.org/browse/JRUBY-5642

Here is the text of that bug echoed here:

We are using JRuby1.6 on Windows and porting our big MRI RoR apps to JRuby RoR.

With MRI RoR, we used active_record to create a table named "domains".

When I access the same database (postgres 8) with JRuby using arjdbc, the active_record call "Domain.column_names" yields a union of the actual column names and the columns names of an internal postgres metadata table named "domains" in the "information_schema" of the Catalog.

The search_path of our database was and still is the default, which is "$user",public.

My current workaround is the set "schema_search_path" to "public" in my database.yml file which seems to force arjdbc to do the right thing. I can track down the code all the way to the file:

activerecord-jdbc-adapter-1.1.1/src/java/arjdbc/jdbc/RubyJdbcConnection.java

which has a method named 'columns_internal'. When I set my schema_search_path, the schema is passed into 'columns_internal' and all is good. Without it, I get the union and all hell breaks loose.

Clearly, I could be doing something wrong since I'm not a java nor postgres expert. But also, there is a chance that arjdbc hasn't run into the case where someone using active_record created a table with the same name as a postgres internal table.

BTW all the other tables that don't clash work just fine.

Jeff

Using rails 3.1 final and activerecord-jdbc-adapter-1.1.3 migrations throw this exception.

private method `split' called for #<Arel::InsertManager:0x6fd0fac8>
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/activerecord-jdbc-adapter-1.1.3/lib/arjdbc/postgresql/adapter.rb:250:in `pg_insert'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/activerecord-3.1.0/lib/active_record/migration.rb:727:in `record_version_state_after_migrating'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/activerecord-3.1.0/lib/active_record/migration.rb:688:in `migrate'
org/jruby/RubyProc.java:274:in `call'
org/jruby/RubyProc.java:229:in `call'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/activerecord-3.1.0/lib/active_record/migration.rb:742:in `ddl_transaction'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/activerecord-3.1.0/lib/active_record/connection_adapters/abstract/database_statements.rb:192:in `transaction'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/activerecord-3.1.0/lib/active_record/transactions.rb:208:in `transaction'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/activerecord-3.1.0/lib/active_record/migration.rb:742:in `ddl_transaction'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/activerecord-3.1.0/lib/active_record/migration.rb:686:in `migrate'
org/jruby/RubyArray.java:1603:in `each'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/activerecord-3.1.0/lib/active_record/migration.rb:671:in `migrate'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/activerecord-3.1.0/lib/active_record/migration.rb:549:in `up'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/activerecord-3.1.0/lib/active_record/migration.rb:530:in `migrate'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/activerecord-3.1.0/lib/active_record/railties/databases.rake:161:in `(root)'
org/jruby/RubyProc.java:274:in `call'
org/jruby/RubyProc.java:229:in `call'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/task.rb:205:in `execute'
org/jruby/RubyArray.java:1603:in `each'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/task.rb:200:in `execute'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/task.rb:158:in `invoke_with_call_chain'
/Users/plentz/.rvm/rubies/jruby-1.6.4/lib/ruby/1.8/monitor.rb:191:in `mon_synchronize'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/task.rb:151:in `invoke_with_call_chain'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/task.rb:144:in `invoke'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/application.rb:112:in `invoke_task'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/application.rb:90:in `top_level'
org/jruby/RubyArray.java:1603:in `each'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/application.rb:90:in `top_level'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/application.rb:129:in `standard_exception_handling'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/application.rb:84:in `top_level'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/application.rb:62:in `run'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/application.rb:129:in `standard_exception_handling'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/rake-0.9.2/lib/rake/application.rb:59:in `run'
/Users/plentz/.rvm/gems/jruby-1.6.4/gems/rake-0.9.2/bin/rake:32:in `(root)'
org/jruby/RubyKernel.java:1063:in `load'
/Users/plentz/.rvm/gems/jruby-1.6.4/bin/rake:19:in `(root)'
Tasks: TOP => db:migrate

I am migrating a project from MRI Ruby and Rails 2.x to JRuby and Rails
3. The app is not very complex, but it does use two databases - one
Postgres database that is the main application database, and one SQL
Server database from which I bring in some extra information (I do not
write to this DB or do any migrations on it)

This worked well until the port. Accessing the SQL Server database now
gives this error:

undefined method `identity=' for

ActiveRecord::ConnectionAdapters::JdbcColumn:0x13d285f

Oddly enough, if I start "rails console" and use the AR model that is
connected to SQL Server, I can run queries just fine, including the one
that caused the error above.

I spent some time trying to find a minimal repro, and I have a very small
Rails that is a repro for this problem. First, some general information.
Gems referred to in my Gemfile:

• rails 3.0.1
• activerecord-jdbcpostgresql-adapter 1.1.1
• activerecord-jdbcmssql-adapter 1.1.1

User is an AR class referencing the postgres database
Registration is an AR class referencing the SQL Server database.

The test controller that produces the problem:

class TestController < ApplicationController
def index
@cur_user = User.find_or_create_by_name("bob")
Registration.find_all_by_activation_id(:first)
render :text => "hi"
end
end

Commenting out the line starting with @cur_user causes the problem to
stop happening.

I posted this in the JRuby forum, and Nick asked me to repost here.

Thanks
Andrew

Hi,

I'm using JRuby 1.6.1 (ruby-1.9.2-p136) on Windows, and activerecord-jdbc-adapter 1.1.1 to connect to an Oracle database and have an issue (not sure if it's activerecord-jdbc-adapter that's at fault or not!).

I've created a new Rails 3 app as per the Readme and scaffolded a single model. When I try to run rake db:migrate, I get the following error:

$ jruby --1.9 -S rake db:migrate --trace
(in C:/cygwin/home/isenrob/development/sites/rail3_rob_test)
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:migrate
rake aborted!
Table SCHEMA_MIGRATIONS does not exist
arjdbc/jdbc/RubyJdbcConnection.java:121:in `columns'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/activerecord-jdbc-adapter-1.1.1/lib/arjdbc/oracle/adapter.rb:337:in `columns'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/arel-2.0.9/lib/arel/table.rb:97:in `columns'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/arel-2.0.9/lib/arel/table.rb:104:in `[]'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/activerecord-3.0.7/lib/active_record/migration.rb:454:in `get_all_versions'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/activerecord-3.0.7/lib/active_record/migration.rb:583:in `migrated'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/activerecord-3.0.7/lib/active_record/migration.rb:492:in `current_version'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/activerecord-3.0.7/lib/active_record/migration.rb:509:in `migrate'
org/jruby/RubyEnumerable.java:552:in `detect'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/activerecord-3.0.7/lib/active_record/migration.rb:509:in `migrate'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/activerecord-3.0.7/lib/active_record/migration.rb:433:in `up'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/activerecord-3.0.7/lib/active_record/migration.rb:415:in `migrate'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/activerecord-3.0.7/lib/active_record/railties/databases.rake:142:in `(root)'
org/jruby/RubyProc.java:256:in `call'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:636:in `execute'
org/jruby/RubyArray.java:1602:in `each'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:631:in `execute'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:597:in `invoke_with_call_chain'
C:/jruby-1.6.1/lib/ruby/1.9/monitor.rb:201:in `mon_synchronize'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:590:in `invoke_with_call_chain'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:583:in `invoke'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2051:in `invoke_task'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `top_level'
org/jruby/RubyArray.java:1602:in `each'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `top_level'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2023:in `top_level'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2001:in `run'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:1998:in `run'
C:/jruby-1.6.1/lib/ruby/gems/1.8/gems/rake-0.8.7/bin/rake:31:in `(root)'
org/jruby/RubyKernel.java:1073:in `load'
C:/jruby-1.6.1/bin/rake:19:in `(root)'

It seems like the SCHEMA_MIGRATIONS table doesn't get created correctly for some reason. However, I can manually connect to the database with ActiveRecord like this:

require 'rubygems'
require 'activerecord-jdbc-adapter'
require 'active_record'
require 'active_record/version'

ActiveRecord::Base.establish_connection(
   :adapter => 'jdbc',
   :driver => 'oracle.jdbc.driver.OracleDriver',
   :url => 'jdbc:oracle:thin:@server.somewhere.com:1521:APP_SID',
   :username=>'myuser',
   :password=>'mypass'
 )

and then I'm able to execute SQL including creating and dropping tables etc, successfully. I can even create a table named SCHEMA_MIGRATIONS myself, and when I do, the migration will run.

I found the following post which looks like a similar issue possibly: http://www.ruby-forum.com/topic/1653203

Would appreciate any advice or help in how to resolve this issue.

Thanks,

Rob

More Info

JRuby / Ruby version info:

$ jruby --1.9 -v
jruby 1.6.1 (ruby-1.9.2-p136) (2011-04-12 85838f6) (Java HotSpot(TM) Client VM 1.6.0_22) [Windows 7-x86-java]

database.yml extract:

development:
  adapter: jdbc
  username: myuser
  password: mypass
  driver: oracle.jdbc.OracleDriver
  url: jdbc:oracle:thin:@server.somewhere.com:1521:APP_SID

Gemfile extract:

platforms :jruby do
  gem 'activerecord-jdbc-adapter'
end

1st failure should be enough to reproduce the issue. https://github.com/plentz/jruby_report

It works just by downgrading back to 3.0.10

Hi,

class Activity < ActiveRecord::Base
set_table_name("test.activities")
set_sequence_name("test.activities_seq")
end

Creating a new record doesn't work. It throws this exception:

ActiveRecord::StatementInvalid: ActiveRecord::JDBCError: ORA-01008: ....

The reason for this exception seems to be that the select for getting the next sequence value is not executed. No log entry for this operation, only for the insert.

It works with normal ruby.

Best regards
Oliver

When column default is nil (null) sqlite3 jdbc adapter return "" (blank string) instead of nil.

TestModelItem.columns
 => [#<ActiveRecord::ConnectionAdapters::SQLite3Column:0x10fba16 @precision=nil, @name="id", @default=nil, @scale=nil, @type=:integer, @limit=nil, @primary=true, @null=false, @sql_type="integer">, #<ActiveRecord::ConnectionAdapters::SQLite3Column:0xb83d5a @precision=nil, @name="test_integer_column", @default="", @scale=nil, @type=:integer, @limit=nil, @primary=false, @null=true, @sql_type="integer">, #<ActiveRecord::ConnectionAdapters::SQLite3Column:0x1c3e11b @precision=nil, @name="created_at", @default="", @scale=nil, @type=:datetime, @limit=nil, @primary=false, @null=true, @sql_type="datetime">, #<ActiveRecord::ConnectionAdapters::SQLite3Column:0xefbaac @precision=nil, @name="updated_at", @default="", @scale=nil, @type=:datetime, @limit=nil, @primary=false, @null=true, @sql_type="datetime">] 
jruby-1.6.3 > c[1]
 => #<ActiveRecord::ConnectionAdapters::SQLite3Column:0xb83d5a @precision=nil, @name="test_integer_column", @default="", @scale=nil, @type=:integer, @limit=nil, @primary=false, @null=true, @sql_type="integer"> 

as you can see, @default="" instead of nil

In java jdbc-sqlite seems that all work fine:

include Java
require '/home/rap-kasta/.rvm/gems/jruby-1.6.3/gems/jdbc-sqlite3-3.7.2/lib/sqlite-jdbc-3.7.2.jar'
include_class Java::java.sql.Connection;
include_class Java::java.sql.DriverManager;
include_class Java::java.sql.ResultSet;
include_class Java::java.sql.SQLException;
include_class Java::java.sql.Statement;
include_class Java::org.sqlite.JDBC

begin

  connection = DriverManager.get_connection("jdbc:sqlite:db/development.sqlite3")
  metadata=connection.get_meta_data
  columns=metadata.get_columns(nil,"%","test_model_items","%")

  for i in 1..4 do
    columns.next
    puts columns.get_string("COLUMN_NAME")
    puts columns.get_string("COLUMN_DEF")
  end
rescue SQLException=>e
  puts(e.message)
end

return:

id
nil
test_integer_column
nil
created_at
nil
updated_at
nil

Hello,

I'm using Composite Primary Keys with Rails 3, Oracle and jruby / activerecord-jdbc-adapter.
ActiveRecord-JDBC-Adapter overrides arel_attributes_values (quoted_primary_key.rb),
but this change isn't working with cpk.

Is this a cpk or activerecord-jdbc-adapter issue?

I have commented out all changes in quoted_primary_key.rb
and now my code seams t o work. Is this special handling for Oracle + Rails 3
still necessary?

Regards
Dieter

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

replace_limit_offset! method (lib/arjdbc/db2/adapter.rb) will generate an SQL of the form:

SELECT B.* FROM (
  SELECT A.*, row_number() over () AS internal$rownum FROM (
    SELECT my_table.my_column as alias ORDER BY my_table.my_column
  ) A
) B WHERE B.internal$rownum > #{offset} AND B.internal$rownum <= #{limit + offset}

the former query is not ordered by DB2 on iseries, and it should be like:

SELECT B.* FROM (
  SELECT A.*, row_number() over (ORDER BY alias) AS internal$rownum FROM (
    SELECT my_table.my_column as alias
  ) A
) B WHERE B.internal$rownum > #{offset} AND B.internal$rownum <= #{limit + offset}

To solve it I would need to modify Arel::Visitors::DB2#visit_Arel_Nodes_SelectStatement and Arel::Visitors::DB2#add_limit_offset in arel/visitors/db2.rb and replace_limit_offset! in lib/arjdbc/db2/adapter.rb`, but I don't known how to obtain the aliases for the order by columns. Also I don't know if the change is only necessary for DB2 on iseries or for DB2 in all platforms.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

When using a active-record model that is named after a MS SQL reserved word, the generated query fails to properly quote the table name with brackets or double quotes. For example I have a User model mapped to a table 'user'. This is a legacy database and renaming the table is not an option

Example model:

class User < UserBase
  set_primary_key "Id"
  set_table_name "user"
end

class UserBase < ActiveRecord::Base
  establish_connection "tums_#{[Rails.env]}"
  self.abstract_class = true
end

Example Resulting Query:

SELECT t.* FROM (SELECT ROW_NUMBER() OVER(ORDER BY user.Id) AS _row_num, user.* FROM user
WHERE user.[Id] = 116329) AS t WHERE t._row_num BETWEEN 1 AND 1

Correct query should look like this:

SELECT t.* FROM (SELECT ROW_NUMBER() OVER(ORDER BY [user].Id) AS _row_num, [user].* FROM [user]
WHERE [user].[Id] = 116329) AS t WHERE t._row_num BETWEEN 1 AND 1

https://github.com/nicksieger/activerecord-jdbc-adapter/blob/26caaab1ff238f1d578e4d08f9ecf49618c00bfb/lib/arjdbc/postgresql/adapter.rb#L429

sometimes generates a binary string and sometimes generates a hexadecimal string:

"010F" will be treated as hexadecimal string
"010E" will be treated as hexadecimal string
"010D" will be treated as hexadecimal string
"010C" will be treated as hexadecimal string
"010B" will be treated as hexadecimal string
"010A" will be treated as hexadecimal string
"0109" will be treated as hexadecimal string
"0108" will be treated as hexadecimal string
"0107" will be treated as hexadecimal string
"0106" will be treated as hexadecimal string
"0105" will be treated as hexadecimal string
"0104" will be treated as hexadecimal string
"0103" will be treated as hexadecimal string
"0102" will be treated as hexadecimal string
"0101" will be treated as binary string
"0100" will be treated as binary string

This ambiguity is highly questionable and should be resolved somehow (maybe hexadecimal strings should be discouraged at all).

Patches from Daniel Schreiber:

the C-Ruby postgresql AR Adapter accepts mutliple schemas in the schema_search_path option. They have to be seperated by comma. The attached patches fix it for me. The C-Ruby AR Adapter restricts the list of tables to schemas specifyed in schema_search_path.

https://gist.github.com/957380

$ bundle exec rake db:create RAILS_ENV=production --trace(in /tmp/test)
** Invoke db:create (first_time)
** Invoke db:load_config (first_time)
** Invoke rails_env (first_time)
** Execute rails_env
** Execute db:load_config
** Execute db:create
rake aborted!
yield called out of block
org/jruby/RubyKernel.java:1770:in tap' /home/zaadjis/.rvm/gems/jruby-1.6.2@bridge/gems/activerecord-jdbc-adapter-1.1.2/lib/arjdbc/jdbc/connection.rb:91:ininitialize'

When running rake test_sqlite3 on master on a windows 7 64bit machine with jruby 1.6.1 I get the following errors:

https://gist.github.com/958232

Hello,

rake db:schema:dump is very slow with activerecord-jdbc-adapter and oracle.
This is because all table statistics are newly generated.

It happens with the following call in RubyJdbcConnection.java:

resultSet = metadata.getIndexInfo(null, schemaName, tableName, false, false);

When the last parameter is set to true,

resultSet = metadata.getIndexInfo(null, schemaName, tableName, false,true);

this call is much faster because table statistics are not
newly generated.

Regards
Dieter

The following code doesn't work properly with activerecord-jdbc-adapter-0.9.7-java
and Rails 2.3.4

MyModel.delete_all
MyModel.cache do
  puts MyModel.all.count
  MyModel.new.save!
  puts  MyModel.all.count
end

expextet output:
0
1

got:

0
0

This happens because changes from ActiveRecord::ConnectionAdapters::QueryCache
are not respected properly.

Work around:

in lib/jdbc_spec/extend_oracle/column.rb

module JdbcSpec
  module ExtendOracle

    module Oracle
      def self.included(base)
        base.class_eval do        
          alias_method :insert_without_query_dirty, :insert
          remove_method :insert
        end
      end
    end
end

in
config/initializers/jdbc_adapter.rb

::JdbcSpec::Oracle.class_eval do
  include JdbcSpec::ExtendOracle::Oracle
end

Regards dieter

https://gist.github.com/784964

This is probably a non-issue, but when working off of master on windows, the following error comes up on just about any rails command

`grep` is not recognized as an internal or external command...

A minor annoyance, but fixable I think...

  #s.files         = `git ls-files | grep -v activerecord-jdbc[^-]`.split("\n")
  s.files = `git ls-files`.split("\n").select{|v| !(v =~ /activerecord-jdbc[^-]/)}

When effectively using the arjdbc postgresql adapter's escape_bytea() or maybe also quote_string() method (see https://github.com/nicksieger/activerecord-jdbc-adapter/blob/26caaab1ff238f1d578e4d08f9ecf49618c00bfb/lib/arjdbc/postgresql/adapter.rb#L439 ), postgresql
complains like this:

WARNING: nonstandard use of \ in a string literal at character 798
HINT: Use the escape string syntax for backslashes, e.g., E''.

These complaints could be turned off, however, then many other relevant log entries of the postgresql log file would
also be turned off, too.

The solution is to properly use postgresql's escape mechanisms, e.g.
http://www.postgresql.org/docs/9.0/static/datatype-binary.html#AEN5037
or http://www.postgresql.org/docs/9.0/static/datatype-binary.html#AEN5046 for bytea-data or just as postgresql itself
suggests the E''-string escape format.