2

i have a problem which is i believe basic for most of the RoR developers. In fact, it's more about "understanding" than really programming it (i have already been programming a few modules to be able to extend ActiveRecord::Base to allow easy generation of Ext-JS related things without any problem).

Let's take a simple example, i'll talk in an ORM oriented language rather than a database / model language.

  • ThirdParty is a basic entity, having a common member named 'label'.
  • A ThirdParty instance can be a Customer, a Supplier, both, or none of them (So Customer / Supplier are like concrete interfaces rather than inherited classes).
  • Both Customer and Supplier have specialized members, which are for most of them unique to each respective class (Customer / Supplier don't share much data except the label field they are bound to via ThirdParty).

i have tried to do various things:

  • ThirdParty < ActiveRecord::Base
  • Customer < ThirdParty
  • Supplier < ThirdParty

[EDIT] Missed my explanation here. i meant: one single instance of ThirdParty could be a customer, a supplier, BOTH, OR NONE. As the first commenter pointed out, my example might not be the best... You can replace "ThirdParty" by "Character", and "Customer" / "Supplier" by "Archer" / "SwordsMan". A character can either be one, two, both, or none, but would provide the information on any instance of Character. The getters on Archer / SwordsMan shall return instances of Character "implementing" the interface contract, rather than just returning an instance of themself with a "getter" on the character object. [/EDIT]

Also i have tried:

  • ThirdParty < ActiveRecord::Base (has_one Customer; has_one Supplier)
  • Customer < ActiveRecord::Base (belongs_to ThirdParty)
  • Supplier < ActiveRecord::Base (belongs_to ThirdParty)

But it seems a bit "ugly" to me, because i have to do Customer.find(something).third_party.label to access data "inherited" by my "interfaces".

Also, i could include a customer_id and a supplier_id field on my ThirdParty model, but it doesn't seem right neither, because one ThirdParty can be both, or none of them...

And of course, i'd like to be able to find a solution which isn't obstructive / too much of a hack, to allow me for instance to then do some polymorphic association for another model (Such as an addressable, or commentable, contactable, etc...)

i also have been reading a lot on the subject like on such blog: http://mediumexposure.com/multiple-table-inheritance-active-record/ ... But i'am lost in the right way to do it (On most of the documentation i have found on the subject isn't clear if it's for Rails 1, 2, 3... What's recently been implemented on the matter, etc).

Can someone provide me with various "up-to-date" websites or to an example fitting the example i have given?

By advance, i thank you all for having red my question, and to edventually explain me the different techniques used regarding this particular subject.

P.S.: If you need me to explain more what i'm looking for, i can try... But keep in mind that my english is a bit "limited" on this domain, since i'm relatively new to RoR.

Doodloo
  • 869
  • 5
  • 18
  • Is there really enough common between `Customer` and `Supplier` to warrant a class hierarchy to join them? It sounds like you have one member field that is shared between them, and this feels like a lot of machinery to avoid the duplication of one field. – sarnold Mar 17 '11 at 23:19
  • My example is in fact just an example. Let's say it's a game character system then... Character can be Archer, Swordman, etc. All of them, or none of them, but it still would be a "person" character. i'd just like to see a solution matching the example to better represent myself how it can be achieved. – Doodloo Mar 18 '11 at 00:41
  • Pierre, thanks, I see now :) Your second example is good too, but I'm not really in a position to suggest anything better than what you've tried. :) – sarnold Mar 18 '11 at 01:11
  • No problem, thanks for reading anyway ;) – Doodloo Mar 18 '11 at 01:29
  • 2
    In your sti example Customer.all should only return customers, not all ThirdParties. Make sure you add a type column. – Alan Peabody Mar 18 '11 at 02:57
  • I use STI in my apps and the only requirement is to include a type column in the table. Also make sure you are creating your records using the appropriate subclass. – Alternegro Mar 18 '11 at 03:36
  • As i said, the first solution won't solve my problem... i want a given instance of Customer to be able to be one, two, none, or both of the subclasses (Interfaces) at the same time... – Doodloo Mar 18 '11 at 19:58
  • Added an EDITED section in my initial topic for clarification :) – Doodloo Mar 18 '11 at 20:04

2 Answers2

3

Having only one field in common, single (or multiple) table inheritance probably isn't the way to go. If you want to share functionality between the classes I would create a ThirdParty module that gets included into each class:

module ThirdParty
  def self.included(base)
    base.extend ClassMethods
  end

  module ClassMethods
    # define your shared class methods here
  end

  # define you shared instance methods down here
end

class Customer < ActiveRecord::Base
  include ThirdParty
end

class Supplier < ActiveRecord::Base
  include ThirdParty
end

This allows you to define methods that utilize the label attribute of each including class. You mention that you'd like to be able to interface with other models, possibly polymorphically. If these associations are present in all ThirdParty objects then you would just setup the associations in either the self.included call (using instance_eval) or in ClassMethods as a method:

module ThirdParty
  def self.included(base)
    base.extend ClassMethods
    base.instance_eval do
      has_many :buyers, :as => :third_party
    end
  end

  module ClassMethods
    def has_address
      has_one :address, :as => :third_party
      delegate :street, :city, :state, :zip, :to => :address
    end
  end
end

class Supplier < ActiveRecord::Base
  include ThirdParty # this would set up the :buyers association

  has_address # this sets up the address association
end

Hopefully that helps. For more information on doing stuff like this just google "ruby mixin" - there's ton of info out there.

mnelson
  • 2,992
  • 1
  • 17
  • 19
1

I recently forked a promising project to implement multiple table inheritance and class inheritance in Rails. I have spent a few days subjecting it to rapid development, fixes, commenting and documentation and have re-released it as CITIER (Class Inheritance and Table Inheritance Embeddings for Rails).

I think you could potentially combine it with the answers above?

Consider giving it a look: http://peterhamilton.github.com/citier

Essentially you could have common fields in your ThirdParty class and create a Customer or Supplier object which inherits them.

You could create a module with functions used in both of them and share that between them?

CITIER wouldn't allow you to have a third party being a Customer and Supplier at the same time as it relies on Ruby inheritance which doesn't support Multiple inheritance. I would imagine some sort of shared module solution would make that part work?

In fact, CITIER already uses something similar to the answer above so would see the right track.

Pete Hamilton
  • 7,730
  • 6
  • 33
  • 58
  • this gem doesn't seem to be well-maintained – keruilin Feb 25 '12 at 04:52
  • Agreed, I have been working on a new version but the current one hasn't been maintained for a while and I have relied heavily on community input. I hope to make it more solid in future and hence more commercially viable. – Pete Hamilton Feb 25 '12 at 15:24