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

rubyonrails-core
1

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

2

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

3

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.

4

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

5

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