abstract_class... what exactly does it do

Does anyone know much about abstract_class? Does it actually prevent
instances of the class from being created? Does it disable certain
methods? I already know what it's for, but I want to know what setting
self.abstract_class=true actually does.

The reason I ask is that I want to use it for a slightly unorthodox
purpose. I want a class who's only attributes are its associated
objects... and as there are no belongs_to associations, it doesn't
need a table. If abstract_class can't do this for me, I'll have to
redefine some methods to prevent AR from looking for a table. (Believe
me, I have tried to refactor my model structure, and this seems like
by far the best option.)

I’m new to all this, but if it doesnt need a table why does it need to be an Active Record?

Ryan Angilly wrote:

I'm new to all this, but if it doesnt need a table why does it need to
be an Active Record?

I need access to the has_many association. I guess I could just find
all the code associated with has_many, and copy it, but that's not
very DRY, and I'd prefer another, cleaner way.

Daniel Waite wrote:

Good question. You can write regular Ruby classes, and those classes can
access your Rails models. I do it all the time. You can check out some
examples in the Typo or Mephisto Tracs.

So are you saying abstract_class works how I want it to?

An abstract class in the general programming sense is defined as a
class which has no instances, but is used to maintain class
relationships. But I want to create instances of a class where
abstract_class is set to true, and just use that as a convenient way
to tell AR that this class has no children.


Thanks for that... the article didn't directly address what I was
looking for, but it strongly implies that abstract_class can do what I
want. I'll keep going with it, and if it falls over later in
development, I'll just have to find another way.

One of the main use cases for making an abstract ActiveRecord class is
to allow an app to work with multiple databases simultaneously.
ActiveRecord objects look up the class chain for their connection, so
by having a separate abstract ActiveRecord class other than
ActiveRecord::Base you can group the models so that they each share
the connection to the proper DB.

For example, I'm currently working on a project which is an
internet-facing front-end which talks to a back-end server inside a
firewall. There's a local database which holds models relevant to
talking to the user, and a remote database behind the firewall.

I've got an abstract AR model which the models for tables on the
remote database subclass. In environment.rb I call
establish_connection on the abstract class with the proper connection
parameters. The local models subclass ActiveRecord::Base and get the
standard setup.