Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The safest way to handle migrations of this nature, Heroku or no, is to strictly adopt a compatibility approach with your schema and code: </p> <ul> <li>Every additive or transformative schema change must be backwards-compatible;</li> <li>Every destructive schema change must be performed <em>after</em> the code that depends on it has been removed;</li> <li>Every code change must either be: <ul> <li>durable against the possibility that associated schema changes have not yet been made (for instance, removing a model or a field on a model) <em>or</em></li> <li>made only after the associated schema change has been performed (adding a model or a field on a model)</li> </ul></li> </ul> <p>If you need to make a significant transformation of a model, this approach might require the following steps:</p> <ul> <li>Create a new database table to hold your new model structure, and deploy that migration</li> <li>Create a new model with the new structure, and code to copy changes from the old model to the new model when the old model changes, and deploy that code</li> <li>Execute a migration or code action to copy all old model data to the new model</li> <li>Update your codebase to use the new model rather than the old model, deleting the old model, and deploy that code</li> <li>Execute a migration to delete the old model structure from the database</li> </ul> <p>With some thought and planning, it can be used for more drastic changes as well: </p> <ul> <li>Deploy code that completely removes dependence on a section of the database, presumably replacing those sections of the site with maintenance pages</li> <li>Deploy a migration that makes drastic changes that would not for whatever reason work with the above dual-model workflow</li> <li>Deploy code that brings the affected sections back with the new model structure supported</li> </ul> <p>This can be hard to organize and requires strict discipline and firm understanding of your code's interaction with your database, but in practice, it <strong>does</strong> allow for most changes to be made with no more downtime than the server restart itself imposes. </p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload