Что является лучшей стратегией миграции для GAE CloudSQL

Question

Я не могу на всю жизнь найти документацию о том, как обрабатывать миграции с помощью Google App Engine и CloudSQL. Я использую среду выполнения Go.

Очевидно, что схема приложения будет меняться и развиваться с течением времени, и миграция должна выполняться. В настоящее время я запускаю миграцию вручную. Это не масштабируемо.

Есть ли у кого есть решение?

Я вижу некоторые специфические проблемы:

• я могу получить версию текущего app.yaml развернутой версии с использованием VersionID. Однако как проверить, произошла ли миграция для этой версии? Мне нужно было бы сохранить номер версии в таблице db и проверить ее в функции init()?

• Однако, когда вы загружаете новую версию приложения, с новой схемой GAE будет медленно migrate your traffic что означает, как только первый экземпляр init() в новой версии работает, и миграция завершается, трафик на старую версию будет сбой в этих транзакциях db.

• Я мог бы немного смягчить проблему выше, выполнив версию моего API. Но это ограничивает стратегии миграции, такие как удаление таблиц и т.д.

Наконец, я разочарован тем, что нет documentation на это, насколько я могу судить.

Answer 1

Я должен согласиться с Робертом, что, хотя это сложная ситуация, это очень мало связано с CloudSQL. В значительной степени любая ситуация, когда вам нужно перенести две версии приложения с различными схемами SQL, создаст эту ситуацию.

Вы в основном есть два варианта

• Сделать все ваши изменения, по крайней мере временно обратную совместимость. Это может включать промежуточную версию вашего приложения, которая может изящно обрабатывать обе версии схемы.

• Версия вашего приложения/API, как вы описываете, связывает данную версию с данной схемой и использует другую базу данных, которая может потребовать копирования данных между двумя базами данных, которые могут использовать гораздо больше хранилища, чем вы хотели бы ,

Совместимый с обратной стороной подход обычно является лучшим, хотя вы получаете некоторый уродливый код для обработки различных схем. Но это обычно можно сделать.

Вы спрашиваете, как вы получаете, имеет ли данная версия заданную миграцию, но помните, что миграция является атрибутом базы данных, а версия является атрибутом приложения. Таким образом, на самом деле вопрос заключается именно в той базе данных, с которой разговаривает версия, и в чем заключается схема для этой базы данных. Ваша идея для номера «версии» для миграции в базе данных на самом деле довольно разумна, и у многих ORM есть какая-то особенность.

Тот факт, что эта проблема существует, заключается в том, что обычно лучше с более гибкими подходами к моделированию данных при первом прототипировании вашего приложения (разрешить больше NULL, не использовать внешние ключи или просто использовать подход NoSQL, такой как Datastore), и реализовать большую целостность данных, как только у вас появится больше уверенности в вашей модели данных.

Наконец, я работаю над документацией Google Cloud, и я сожалею, если вы разочарованы, мы не обращаемся к этому более четко, но, надеюсь, вы понимаете, что это общий вопрос по операциям с базой данных, а не вопрос, Google Cloud или App Engine. Если вы придумаете решение, которое вам нравится, вы должны подумать об этом в блогах, и мы будем рады помочь вашему решению!