7

I know there are some questions to this effect already on StackOverflow, but they tend to be pretty outdated and don't adequately address how migrations are supposed to work in the following scenario, which should be fairly common:

  • You have some kind of application, implemented in Rails.
  • You have some kind of admin application for your data, and it is a separate application implemented in Rails.
  • Both applications operate on the same database and models.

My question is: what is the best way to factor our models such that both of these applications don't have to duplicate model code?

We are concerned with the following:

  • For the shared models, where should database migrations live?
  • What if each individual application wishes to add additional models on top of shared models? Where do these migrations live?
  • What is the best way to move existing migrations into the proposed shared migration scheme?

Thanks.

Jake
  • 15,007
  • 22
  • 70
  • 86

1 Answers1

1

I don't know if this is THE approach, and would love to see other ideas, but what we do in one of our products that matches this model:

For the shared models, where should database migrations live?

We keep all of our migrations under the admin system. You don't need them to exist twice, so that's where they go.

What if each individual application wishes to add additional models on top of shared models? Where do these migrations live?

We share all models. It might only be relevant to one application at the moment, say - a favourited_items concept might only matter to the end user. But at a later date the admin might want to know what items are most frequently favourited.

Secondly, if you want to investigate anything via console, it's really quite helpful if you don't need to visit separate applications because they don't both have models for every table.

Functionality in shared models that differs per application detects the rails environment variable, which we have extended to include more context. E.g.: if Rails.env == 'admin_production'

What is the best way to move existing migrations into the proposed shared migration scheme?

Again, migrations should only ever exist once, and the shared database knows which have already been run, so unless you're renaming the migrates you just need to pick a location and move the files.

Matt
  • 13,948
  • 6
  • 44
  • 68
  • Thanks, that makes sense. Now for sharing models, are you using a library, a Rails engine, or something else? – Jake Mar 24 '16 at 15:31
  • We use symlinks (or similar) from the "slave" applications pointing to the master files. – Matt Mar 24 '16 at 15:35