jruby/activerecord-jdbc-adapter — Issue #155: db:migrate rake abort with message "undefined method `accept' for nil:NilClass"
Author: headius
Created: 2012-01-24 02:12:19+00:00
State: open

Originally reported at https://jira.codehaus.org/browse/JRUBY-6363

The trace you see when trying to migrate something under Rails 3.2:

```
rake db:migrate --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
rake aborted!
undefined method `accept' for nil:NilClass
/home/mauro/jruby-1.6.5.1/lib/ruby/gems/1.8/gems/activerecord-3.2.0/lib/active_record/connection_adapters/abstract/database_statements.rb:7:in `to_sql'
```

The problem here is that the built-in adapters initializers now do some extra logic to set up the Arel visitor, which is what's "nil" above. Here's the logic from Rails built-in SQLiteAdapter:

```
def initialize(connection, logger, config)
super(connection, logger)
@statements = StatementPool.new(@connection,
config.fetch(:statement_limit) { 1000 })
@config = config
@visitor = Arel::Visitors::SQLite.new self
end
```

Our logic unfortunately does not extend Rails' logic, so we don't inherit this behavior. I'm not sure the best way to get it in other than copy/pasting, but then we're probably depending on stuff that's Rails 3.2+ only. Here's our logic (abbreviated) for SQLite:

```
module ActiveRecord::ConnectionAdapters
remove_const(:SQLite3Adapter) if const_defined?(:SQLite3Adapter)
remove_const(:SQLiteAdapter) if const_defined?(:SQLiteAdapter)

...

class SQLite3Adapter < JdbcAdapter
include ArJdbc::SQLite3

def jdbc_connection_class(spec)
::ArJdbc::SQLite3.jdbc_connection_class
end

def jdbc_column_class
ActiveRecord::ConnectionAdapters::SQLite3Column
end

alias_chained_method :columns, :query_cache, :jdbc_columns

protected

def last_inserted_id(result)
last_insert_id
end
end

SQLiteAdapter = SQLite3Adapter
end
```

As you can see, we're not doing the logic that Rails does, and not inheriting that logic either.