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
on 04.05.2008 00:56
on 04.05.2008 01:27
On Sun, May 4, 2008 at 12:56 AM, Kenneth Kalmer <kenneth.kalmer@gmail.com> wrote: > ActiveRecord::Legacy.configurations from another yml file, and this > 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
on 04.05.2008 02:30
> 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
on 08.05.2008 11:45
On Sun, May 4, 2008 at 2:29 AM, Michael Koziarski <michael@koziarski.com> wrote: > 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
on 09.05.2008 00:27
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