views:

138

answers:

2

I've run into a situation that I am not quite sure how to model.

EDIT: The code below now represent a working solution. I am still interested in nicer looking solutions, though.

Suppose I have a User class, and a user has many services. However, these services are quite different, for example a MailService and a BackupService, so single table inheritance won't do. Instead, I am thinking of using polymorphic associations together with an abstract base class:

class User < ActiveRecord::Base
    has_many :services
end

class Service < ActiveRecord::Base
    validates_presence_of :user_id, :implementation_id, :implementation_type
    validates_uniqueness_of :user_id, :scope => :implementation_type

    belongs_to :user
    belongs_to :implementation, :polymorphic => true, :dependent => :destroy
    delegate :common_service_method, :name, :to => :implementation
end

#Base class for service implementations
    class ServiceImplementation < ActiveRecord::Base
    validates_presence_of :user_id, :on => :create

    #Virtual attribute, allows us to create service implementations in one step
    attr_accessor :user_id
    has_one :service, :as => :implementation

    after_create :create_service_record

    #Tell Rails this class does not use a table.
    def self.abstract_class?
        true
    end

    #Name of the service.
    def name
        self.class.name
    end

    #Returns the user this service
    #implementation belongs to.
    def user
        unless service.nil? 
            service.user
        else #Service not yet created
            @my_user ||= User.find(user_id) rescue nil
        end
    end

    #Sets the user this 
    #implementation belongs to.
    def user=(usr)
        @my_user = usr
        user_id = usr.id
    end

    protected

    #Sets up a service object after object creation.
    def create_service_record
        service = Service.new(:user_id => user_id)
        service.implementation = self
        service.save!
    end
end
class MailService < ServiceImplementation
   #validations, etc...
   def common_service_method
     puts "MailService implementation of common service method"
   end
end

#Example usage
MailService.create(..., :user => user)
BackupService.create(...., :user => user)

user.services.each do |s|
    puts "#{user.name} is using #{s.name}"
end #Daniel is using MailService, Daniel is using BackupService

Notice that I want the Service instance to be implictly created when I create a new service.

So, is this the best solution? Or even a good one? How have you solved this kind of problem?

A: 

I think following will work

in user.rb

  has_many :mail_service, :class_name => 'Service'
  has_many :backup_service, :class_name => 'Service'

in service.rb

  belongs_to :mail_user, :class_name => 'User', :foreign_key => 'user_id', :conditions=> is_mail=true
  belongs_to :backup_user, :class_name => 'User', :foreign_key => 'user_id', :conditions=> is_mail=false
Salil
That won't do. I do not want User to know specifics about the services, only that they conform to a specific interface.
Daniel Abrahamsson
+2  A: 

I don't think your current solution will work. If ServiceImplementation is abstract, what will the associated classes point to? How does the other end of the has_one work, if ServiceImplementation doesn't have a pk persisted to the database? Maybe I'm missing something.

EDIT: Whoops, my original didn't work either. But the idea is still there. Instead of a module, go ahead and use Service with STI instead of polymorphism, and extend it with individual implementations. I think you're stuck with STI and a bunch of unused columns across different implementations, or rethinking the services relationship in general. The delegation solution you have might work as a separate ActiveRecord, but I don't see how it works as abstract if it has to have a has_one relationship.

EDIT: So instead of your original abstract solution, why not persist the delgates? You'd have to have separate tables for MailServiceDelegate and BackupServiceDelegate -- not sure how to get around that if you want to avoid all the null columns with pure STI. You can use a module with the delgate classes to capture the common relationships and validations, etc. Sorry it took me a couple of passes to catch up with your problem:

class User < ActiveRecord::Base
  has_many :services
end

class Service < ActiveRecord::Base
  validates_presence_of :user_id
  belongs_to :user
  belongs_to :service_delegate, :polymorphic => true
  delegate :common_service_method, :name, :to => :service_delegate
end

class MailServiceDelegate < ActiveRecord::Base
   include ServiceDelegate

   def name
     # implement
   end

   def common_service_method
      # implement
   end
end

class BackupServiceDelegate < ActiveRecord::Base
   include ServiceDelegate

   def name
     # implement
   end

   def common_service_method
      # implement
   end
end

module ServiceDelegate
   def self.included(base)
     base.has_one :service, :as => service_delegate
   end

   def name
     raise "Not Implemented"
   end

   def common_service_method
     raise "Not Implemented"
   end
end
Dave Sims
Nice solution! However, I've got my own suggested solution to work well now. It is basically the same as yours, except I use an abstract class instead of a module. I will update the code soon, so it is easier to compare.
Daniel Abrahamsson
I am accepting your answer as it is closest to my own final solution.
Daniel Abrahamsson