Rails core - May 2008 - 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

-- 

Kenneth Kalmer
kenneth.kalmer@gmail.com

Folding@home stats
http://fah-web.stanford.edu/cgi-bin/main.py?qtype=userpage&username=kenneth%2Ekalmer

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On Sun, May 4, 2008 at 12:56 AM, Kenneth Kalmer
<kenneth.kalmer@gmail.com> wrote:
>  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.
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


-- 

Kenneth Kalmer
kenneth.kalmer@gmail.com

Folding@home stats
http://fah-web.stanford.edu/cgi-bin/main.py?qtype=userpage&username=kenneth%2Ekalmer

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

>  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.

-- 
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On Sun, May 4, 2008 at 2:29 AM, Michael Koziarski <michael@koziarski.com>
wrote:
>
>  >  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


-- 

Kenneth Kalmer
kenneth.kalmer@gmail.com

Folding@home stats
http://fah-web.stanford.edu/cgi-bin/main.py?qtype=userpage&username=kenneth%2Ekalmer

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On Thu, May 8, 2008 at 2:44 AM, Kenneth Kalmer <kenneth.kalmer@gmail.com>
wrote:
>
> 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.
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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---