Persist relation to a class (and not a class instance) in Ruby on Rails with Mongoid

Question

Assume my users can subscribe to several plan_types. I want to define those plans as classes, and be able to keep, for each user, a reference to a subscription_plan and also a presubscription_plan. This is like a State pattern :

class Payment::SubscriptionPlan
 def self.max_subscription_quantity
 120
 end 
end
class Payment::ConcretePlan1 < Payment::SubscriptionPlan
 def self.commitment_period
 2.months
 end
end
class Payment::ConcretePlan2 < Payment::SubscriptionPlan
 def self.max_subscription_quantity
 50
 end
end

What is the best way to "persist" the relation to a class in the database ? Currently I was doing the following using the as_enum gem

class Settings
 setting :subscription_plans, type: Array, default: [
 Payment::ConcretePlan1, 
 Payment::ConcretePlan2
 ]
end
class User
 as_enum :subscription_plan, Settings.subscription_plans, map: :string
 as_enum :presubscription_plan, Settings.subscription_plans, map: :string
 def subscription_plan
 return nil if super.nil?
 Payment.const_get(super.to_s.demodulize)
 end
 def presubscription_plan
 return nil if super.nil?
 Payment.const_get(super.to_s.demodulize)
 end
end

The current implementation works but I'm not sure this is the best way to tackle the problem

• BenKoshy: ConcretePlan1 has a subscription period where as the other plans do not. Shouldn't all plans also have a subscription period? If these classes are just placeholders for returning a particular value, you can have that same functionality?
• Cyril Duchon-Doris: Some payment systems involve automatic payment where I need to specify a period (eg. Stripe), whereas some other subscriptions are managed from the outside. I have factories to handle the subscriptions but I need to save the type of subscription for that :D And actually no commitment_period is a bit different than the subscription period : for monthly payment, our offer stipulates that you have to pay for at least 3 months when you start a subscription. When paying yearly, no such commitment period apply.

Answer 1

It works that's for sure.

But enums could just as easily be defined in the database. Now that you've already got it working with enums, I would say stick with enums untill you have a good reason to change it.

anyways, here's how i probably would have done it:

e.g.

• user has_many subscription_plans
• subscription_plan can belong to many users.
• Limit the ability for a user to have a max of two, one of each type. Or the user must have two at any one time etc.

enter image description here

You get the picture. You can change the subscription plan table to suit your needs.

Hope this helps.

• Cyril Duchon-Doris: Hey thanks. I'm using a class object on my server since I need to define methods on the subscription_plan (subscription_plan.max_quantity, etc.) which is why I want to initialize some Ruby object where I can add whatever methods I want. I edited my example to include this. I'm not just using this as string enum.
• Greg Burghardt: @CyrilDuchon-Doris: You should be able to still add methods and behavior specific to a kind of plan. ActiveRecord allows you to specify a "descriminator" column to instantiate a particular concrete class, giving you some of the benefits of polymorphism.
• Greg Burghardt: Also just realized the OP has a "mongo-db" tag.

Answer 2

It sounds like you really need subscription plans to be data-driven. The methods you are defining on the concrete types are really just data. No need for concrete types. You need a better database table (and I use the term "table" loosely since you tagged the question with mongodb):

| id | name | max_subscription_quantity | commitment_period_num | commitment_period_type |
| 1 | Plan 1 | 120 | 2 | Month |
| 2 | Plan 2 | 50 | NULL | NULL |

There really isn't a need for sub classes. Just one class ought to do it:

class Payment::SubscriptionPlan
 def commitment_period
 # return period based on type and number
 end
end

The only thing you need to define is commitment_period which does the calculation of the commitment_period_num and commitment_period_type columns.