2

I don't know much about migrations, but this is a specific question I'm not sure how to answer.

In production, how can one change the database format/schema when there is already user data in there? (Is the answer different for our Meteor app on MongoDB vs our master Postgres database?) Basically, if you write new code that introduces a new field, and new code that expects that new field to be present, then the system will not work when pulling data from the database that was there prior to the changeover.

For Mongo at least, a possible solution is to write a script to update the database layout with the data in it, but I wonder if this is too error prone for a production database, and infeasible when you just don't have the necessary information (like if you didn't collect a certain info field from the user before.)

  • Well, sure, you'd write a script, and sure, this is done in production databases. But if you didn't collect some piece of information before you are probably going to have to write code that does not assume it will always have access to it. – Casey Oct 22 '14 at 16:42
  • what backup / restore options are there at your prod database? – gnat Oct 22 '14 at 16:51
  • Can you use a default value and handle it in your program? You may need to go out of your way to prompt the user to update these values. – JeffO Oct 22 '14 at 18:37
  • We usually first made new and old data coexist, as much as possible: e.g. by filling new fields with data from old fields, or using synonyms for renamed objects. This allowed old production code to continue working in parallel with new code, and be a viable rollback option if new code starts to behave badly in production. After that, we completed the migration of the DB by dropping the unused old fields / tables. – 9000 Dec 21 '14 at 20:08
3

if you write new code that introduces a new field, and new code that expects that new field to be present, then the system will not work when pulling data from the database that was there prior to the changeover.

You have to take that into account when you are writing your code. You could run a script when you deploy the new changes to populate this field with a default value. You could write your code so that it is able to handle the situation where the field is no present/populated.

Exactly what you do will probably depend on the details of your situation, but you're correct: you have to do something to handle this.

...And it goes without saying that you should test this migration process thoroughly (on a copy of production, if possible) before running it in a production system. ;)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.