I want to share everything about a model except the db connection. Is
this a reasonable way to do it?
module NotebookDefinition
I want to share everything about a model except the db connection. Is
this a reasonable way to do it?
module NotebookDefinition
IF everything is the same except for the dbconnection, you could just
specify the dbconnection you want in each model, or put that in a module
that you include.
From a plugin of mine where the model and the database.yml file are in the
same folder:
class PersonRecord << ActiveRecord::Base
c = YAML::load(File.open(File.dirname(__FILE__) +
“/person_database.yml”))
PersonRecord.establish_connection(
:adapter=>c[RAILS_ENV]['adapter'],
:host=>c[RAILS_ENV]['host'],
:username=>c[RAILS_ENV]['username'],
:password=>c[RAILS_ENV]['password'],
:database=>c[RAILS_ENV]['database']
)
end
You could use modules to put the common code into multiple classes, but
you
could also make a new base class and put the common code in that
class MyBase < ActiveRecord::Base
def foo
"bar’
end
end
class User < MyBase
has_many :projects
c = YAML::load(File.open(File.dirname(FILE) +
“/user_database.yml”))
User.establish_connection(
:adapter=>c[RAILS_ENV]['adapter'],
:host=>c[RAILS_ENV]['host'],
:username=>c[RAILS_ENV]['username'],
:password=>c[RAILS_ENV]['password'],
:database=>c[RAILS_ENV]['database']
)
end
Would that work?
sorry… fat-fingered… I want to share a common definition for each of
the classes, but have all classes within a given module be able to
operate on a separate database from other modules…
module NoteBookDefinition
def import_definition
set_table_name :notebooks
has_many :pages
end
end
class Master::Notebook
extend NotebookDefinition
import_definition
end
class Other::Notebook
extend NotebookDefinition
import_definition
establish_connection :otherdb
end
module PageDefinition
def import_definition
belongs_to :notebook
end
end
class Master::Page
extend PageDefinition
import_definition
end
class Other::Page
extend PageDefinition
import_definition
establish_connection :otherdb
end
n = Master::Notebook.find :first
n.class (returns Master::Notebook)
n.pages[0].class (returns Master::Page)
m = Other::Notebook.find :first
m.class (returns Other::Notebook)
m.pages[0].class (returns Other::Page)
Thanks for the suggestion, Brian… If I specify the dbconnection in
each model, then I’d have to repeat the entire model definition… The
question is, how to best share everything except the dbconnection…
It took a while to come up with the above scheme to share the rest
(relationships, validations, etc) Is that the best way to do it?
-dan
Brian H. wrote:
IF everything is the same except for the dbconnection, you could just
specify the dbconnection you want in each model, or put that in a module
that you include.From a plugin of mine where the model and the database.yml file are in the
same folder:class PersonRecord << ActiveRecord::Base
c = YAML::load(File.open(File.dirname(__FILE__) +
“/person_database.yml”))
PersonRecord.establish_connection( :adapter=>c[RAILS_ENV]['adapter'], :host=>c[RAILS_ENV]['host'], :username=>c[RAILS_ENV]['username'], :password=>c[RAILS_ENV]['password'], :database=>c[RAILS_ENV]['database'] )
end
You could use modules to put the common code into multiple classes, but
you
could also make a new base class and put the common code in thatclass MyBase < ActiveRecord::Base
def foo
"bar’
end
endclass User < MyBase
has_many :projects
c = YAML::load(File.open(File.dirname(FILE) +
“/user_database.yml”))User.establish_connection( :adapter=>c[RAILS_ENV]['adapter'], :host=>c[RAILS_ENV]['host'], :username=>c[RAILS_ENV]['username'], :password=>c[RAILS_ENV]['password'], :database=>c[RAILS_ENV]['database'] )
end
Would that work?
Dan K. wrote:
I want to share everything about a model except the db connection. Is
this a reasonable way to do it?module NotebookDefinition
Please expound on ‘share’. Are we talking subclassing? If so, any model
can redefine the AR’s connection, and all of that class will use the
same connection. Otherwise I’m not sure what you’re hinting at.
Jason
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs