abstract_class... what exactly does it do

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