If I were you I’d stub out all the different objects with ‘shell’ implementations in your master branch, and then AR won’t blow up when it tries to instantiate the objects. Then you can leave implementation details to the branches where you want to implement/test them.
Also it seems odd to me that you have a workflow that consistently creates new objects that will rely on STI implementations. Are all those objects different from eachother? (That is, do they each implement a certain domain logic that can best be implemented with Ruby code). If the answer is no, I’d question whether or not STI is the right pattern for what you are doing. -Jason > On Jan 26, 2015, at 6:24 AM, Xavier Noria <f...@hashref.com> wrote: > > You're facing one possible way to have incompatible schemas between branches. > > They are created by workflows external to Active Record, to me it doesn't > makes sense that Active Record acts in a way it is not supposed to, to > address divergences in Git branches. > > Divergence in Git branches is an external issue, and should be solved where > it is originated in my view, at the workflow level. > > If your application has a very specific use case for STI it could be the case > that your most efficient way to workaround it is by monkey patching something > in AR... that depends on the details. But certainly I don't see the solution > builtin in AR. > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
