Also In the first example, I simplifid too much
usage item entity.
It has more than 4 ~ 6 different column from other types of invocie items. (
subscription item, and
So it's not really like 20 ~ 30 columns.
I think I can still use STI but what do you think?
Thank you so much for the detailed answer. I don't have anyone to ask in our team. (Those who have really good understanding of OR mapping.)
Yes, it's true that STI is not only RoR thing and it's introduced in the book by Bill Karwin.
Also it's introduced PofEAA too!
So it's absolutely decent pattern IMO.
In here the main question is that possible to change to polymorphic from STI in the future?
In an example,
You can see three types of entities.
So for implementation,
subscription item and
proration are similar, but
usage item is a little different from the others.
(So you seem to ues Stripe API as GoRails billing processor. What I does is developing billing system in our application with Stripe.)
We have a mapping layer that sits between the Stripe API and your own internal invoice system to
- generate a completely custom receipt
- store data for an invoice (who get charged for what items)
subscription item and
in the invoice.payment.succeedd webhook, we can just handle and stroe the data. (like which inoivce has which items.)
usage item is basically,
- for extra optional items on top of the subscription (subscription + something)
- Stripe ususally has the cicle that after they send
invoice.createdwebhook, we could add items to the invoice for 1 hour before invoce.payment_succeed/faild trigers (except the very first invoice)
invoice.createdwebhook we can fetch the
usage_itemsand add the
invoice, so that's why it's belongs to an
I wish I could articulate the situation, and you could understand.
However usage_item is not used for now. Maybe in the future.
I totally agree with what you said.
start simple and just pick one that seems most intuitive to you right now.
For now I could delete unused stuff (
So the question here is possible to change to polymorphic from STI in the future?
you can always write migrations to move data into another structure and change your models along with it
It's always scarly to change the db shceme especially table once the application runs in production.
I'd love to hear how I could achieve it efficiently. (Maybe little off the topic, and I'm very new to RoR)
It's okay to restructure the database schema, and what about the data in db, and also downtime to deal with that.
I'd love to hear the reason why I could use some design.
Maybe those types pros and cons.
As far as I know,
If I apply STI
That leads many NULLable columns, but RoR supports STI. So it's easy
If I apply polymorphic with has_one
It stills the rails way but the original polymorphic definition is
different. It should have
has_manyrelationship instead of
has_one. Also it's impossible to add foreign key.
If I apply Class table inheritance,
It's more efficient for relational database, but it's not rails way.
Hi I watch your tuts and it's pretty helpful. Always thanks!
I have some question about database design.
There are three types of invoice items with following tables
Those have the same attributes below
invoice_id amount stripe_invoie_id
only SubscriptionItem and Proration
and only Proration and UsageItem has
and only UsageItem has
uuid account_id description
To achieve this model I've been using polymorphic relation.
class InvoiceItem < ActiveRecord::Base belongs_to :invoice belongs_to :itemable, polymorphic: true end class SubscriptionItem < ActiveRecord::Base belongs_to :plan has_one :invoice_item, as: :itemable end class UsageItem < ActiveRecord::Base belongs_to :account has_one :invoice_item, as: :itemable end class Invoice < ActiveRecord::Base belongs_to :account has_many :invoice_items end class Account < ActiveRecord::Base has_many :invoices has_many :usage_items end
For now it works.
However As far as I understand polymorphic should have
So this resides in the middle of
Because those three types of invoice items are always be subscriptionitem, proration, or usageitem.
It's hard decision that I could keep using this models or use STI instead?
Or Should I use class table inheritance should be fit?