Let's take two simple Rails models, Post and PostRevision.
class Post < ApplicationRecord # Attribute: Status (ex: draft, public, private, deleted) # Attribute: Views # An owner, likely a belongs_to relation. Perhaps a has_many relation. has_many :post_revisions validates :post_revisions, :presence => true has_many :comments has_many :votes # Delegation to most recent active / not deleted PostRevision for title, # body, tags to effectively expose these attributes end class PostRevision < ApplicationRecord belongs_to :post # Attribute: Title # Attribute: Body # Attribute: Status (ex: deleted / not deleted, perhaps just an int flag) # Attribute: Views # Attribute: Revision history notes / text. # If a Post has_many owners, an attribute for author/owner of revision has_many :tags end
The default behavior of the "belongs to" association is to require that the associated record is present (that is, a PostRevision must have a Post - this can be disabled with an argument).
This model is conceptually true, however there's an problem that exhibits itself in test setup and controller actions - see this Stack Overflow question on "1-to-1 or more" relationships in SQL. You can't create a PostRevision until there's a Post, but you need a valid PostRevision to create a Post. I see two options - I can make the "belongs to" relation in the PostRevision optional. This will let me create a PostRevision first then a Post and associate them. Alternatively, I can remove the validation of the existence of a PostRevision on a Post. This would let me create a Post and then multiple PostRevision.
I'm leaning toward the second approach - remove the validation on Post. However, I can't actually put into words why this is the better option, other than it feels more right to create the Post and the things that cut across revisions and then the revision with the rest of the data.
Is there an alternative approach that I haven't considered? If not, is there some kind of rational justification to the approach that I'm leaning toward?