Why isn't ActiveRecord::Base.configurations class_inheritable_accessor?

Hi all

I'm busy writing a gem that uses ActiveRecord to access a legacy
database, and will be used on its own and as a part of Rails
applications. The gem on its own works pretty well so far, but I hit
some snags whilst implementing it into a Rails app for the first time.

I followed what I though would be a safe path to multi-connection
bliss, briefly summarized here:

module ActiveRecord
  class Legacy < Base
    self.abstract_class = true
  end
end

Then during the project initialization I set
ActiveRecord::Legacy.configurations from another yml file, and this
overwrites ActiveRecord::Base.configurations.

I'm pretty well aware that I can connect each model separately to the
legacy database by using ActiveRecord::Legacy.establish_connection
(which is currently what I'm doing). But this is not very DRY. I'm
moving over to using ActiveRecord::Legacy.inherited as a hack to
connect each legacy model, but its still ugly.

Wouldn't changing ActiveRecord::Base.configurations from a
cattr_accessor to class_inheritable_accessor solve this problem while
remaining backward compatible and being more open for multi-database
connections? If each model can have their own database connection,
surely they can have their database configuration as well?

Making a local change now and running all the tests to check what the
impact is, just though I'll put the idea out there in the meantime.

Best

Seems I was talking out my ass, its not that simple.

Now, is this an option work pursuing? I almost wanna dare ask if this
one of those issues that possibly deserve a github fork. I cannot
imagine that I'm the only developer that has hit this barrier, and I'm
definitely not the last one either.

Any suggestions on how we can tackle this?

Best

Now, is this an option work pursuing? I almost wanna dare ask if this
one of those issues that possibly deserve a github fork. I cannot
imagine that I'm the only developer that has hit this barrier, and I'm
definitely not the last one either.

Any suggestions on how we can tackle this?

Perhaps the best bet is to wait just a little bit. We intend to rejig
most of that code in v.next to support connection pools. Nick Sieger
has made a start on it.

We can probably make this use case a little easier at the same time.

Sure sounds like it. Any way in which I can help to make it does
indeed cover this kinda use case at the same time? I'm following
Nick's fork on github to check the progress in the meanwhile.

Best

BTW, I hope to get back to this soon -- was swamped for the past
couple weeks with the lead-up to JavaOne. I'll get the fork rebased
soon and hopefully get some more done.

/Nick