Database - Switching Tables

I have a mailing-list database that consists of several tables (e.g.,
clients table, prospects table, etc.). How can I switch between these
tables within my mailing-list Rails application?

I have a feeling that if I better understood the role of the model I
might be able to answer my own question. I'm hoping that getting this
question answered will help me in that regard.

Thanks for any input.

         ... doug

Hi--

I have a mailing-list database that consists of several tables (e.g.,
clients table, prospects table, etc.). How can I switch between these
tables within my mailing-list Rails application?

I have a feeling that if I better understood the role of the model I
might be able to answer my own question. I'm hoping that getting this
question answered will help me in that regard.

In Rails, a model normally maps to a table. So if you have a clients table, you have a Client model and if your have a prospects table, you have a Prospect model. Rails infers the table name and columns from the name of the model class. So you can do:

send_email_to :clients
send_email_to :prospects

def send_email_to(whom)
   model = whom.to_s.camelize.constantize.all.each do |recipient|
     # recipient is an object of the specified type. Send email at will!
   end
end

In Rails, a model normally maps to a table.

Yes; but, it appears that in this case it would be really nice if I
could have a single model and then somehow simply switch between
associated tables. (I'm not sure that I'm going to be able to do it.)

Rails infers the table name and columns from
the name of the model class.

I understand that default inference. Obviously, if I am able to
succeed at what I am trying to do, I would be overriding that default.

Thanks for the input.

         ... doug

Doug Jolley wrote:

In Rails, a model normally maps to a table.

Yes; but, it appears that in this case it would be really nice if I
could have a single model and then somehow simply switch between
associated tables. (I'm not sure that I'm going to be able to do it.)

Why not just subclass?

class Person < ActiveRecord::Base
  self.abstract_class = true # this will prevent Rails from expecting a
"people" table

  # common features go here
end

class Client < Person
  ...
end

class Prospect < Person
  ...
end

That should do the trick!

Best,

Why not just subclass?

I like that approach. It was essentially what I was playing with when
I submitted my original post. The problem with it seems to be that I
can't reference the subclass. Extending your example, I would like to
say something like:

clients=Client.find(:all)

Rails doesn't like that. It complains that Client is an uninitialized
constant. It appears that Rails wants me to say something like:

clients=Person.find(:all)

IOW, it appears that Rails wants the name of the class to correspond
the base name of the model file (i.e., since the name of the model
file is person.rb, it wants the class to be Person). Without that
correlation, I get the uninitialized constant error. I'm not sure how
to get around the problem. If I could; then, I think your suggestion
would work just fine.

Thanks.

       ... doug

if you decide that abstract classes are better, then I suggest that you
do something like this to make your life easier:

1: class Person < ActiveRecord::Base

2: TypesofPeople = ["Client", "Prospect"]

3: def self.abstract_find (person_type, *args)
4: if TypesofPeople.include?(person_type)
5: person_type.constantize.find(*args)
6: else
7: nil
8: end
9: end

I really wish that I understood your suggestion especially because it
may be what works. I have taken the liberty of adding line numbers.
Basically, I understand the code except for line 5. I have no idea
what you are doing there. I'm not sure what the person_type and *args
are that you are passing to abstract_find. Part of my confusion may
stem from the fact that there does not seem to be and 'end' for your
class definition. So, I'm not altogether clear on whether lines 3
through 9 are suggested model code or suggested controller code.
Could you please clarify? I do appreciate your suggestion and I have
high hopes for it being my salvation. Thanks.

       ... doug

Put each class definition in a separate file

By "separate file" you mean "separate model", right? I guess I could
do that. My concern is that if I do I may be opening and closing the
connection to the database? Maybe I am and maybe I am not. If I am,
maybe I don't need to worry about it; but, I do. That's why I wanted
to let Rails be in charge of handling the connection to the database.
I just want to swap tables.

Maybe I should ask a couple of more basic questions: What, if any,
are the adverse affects associated with switching models from with an
application? If I swap models from within an application, does that
result in closing and re-opening the database?

Thanks.

      ... doug

hope it helps,

Great answer. Love it! :slight_smile: I think that I'm a happy camper.

Thanks to all who contributed.

       ... doug