Подтвердить что ты не робот

Как правильно обрабатывать миграции схем мангуста?

Я совершенно не знаком с MongoDB и Mongoose и не могу найти ответ о том, как обрабатывать миграции при изменении схемы.

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

Как это обычно обрабатывается в MongoDB/Mongoose? Любая информация, о которой я должен знать?

4b9b3361

Ответ 1

В этом и разумном понимании того, как работают миграции в реляционной базе данных, MongoDB делает это немного проще. Я пришел к двум способам преодолеть это. Что нужно учитывать при работе с миграциями данных в MongoDB (не все, что необычно из RDB):

  • Обеспечение локальных тестовых сред не прерывается, когда разработчик объединяет последние из репозитория проекта.
  • Обеспечение правильного обновления любых данных в живой версии независимо от того, вошел ли пользователь в систему или нет, если используется аутентификация. (Конечно, если все автоматически выходят из системы при обновлении, необходимо только беспокоиться о том, когда пользователь входит в систему).

1) Если ваше изменение выйдет из системы или произойдет простоя приложения, тогда простой способ сделать это - переносить script для подключения к локальному или живому MongoDB и обновлять правильные данные. Пример, когда имя пользователя изменяется из одной строки на объект с заданным и фамильным именем (очень простой, и, конечно же, его нужно будет помещать в script для всех разработчиков):

Использование CLI:

mongod
use myDatabase
db.myUsers.find().forEach( function(user){
    var curName = user.name.split(' '); //need some more checks..

    user.name = {given: curName[0], family: curName[1]};
    db.myUsers.save( user );
})

2) Вы хотите, чтобы приложение перенести схемы вверх и вниз на основе версии приложения, которое они запускают. Это, очевидно, будет нелегким бременем для живого сервера и не требует времени простоя из-за обновления только пользователей, когда они впервые используют обновленные/пониженные версии.

Если вы используете промежуточное ПО в Expressjs для Nodejs:

  • Установите переменную приложения в корневое приложение script через app.set('schemaVersion', 1), которое будет использоваться позже для сравнения с версией схемы пользователей.
  • Теперь убедитесь, что все пользовательские схемы имеют свойство schemaVersion, поэтому мы можем обнаружить изменение между версией схемы приложения и текущими схемами MongoDB только для ТОЛЬКО ПОЛЬЗОВАТЕЛЯ.
  • Далее нам нужно создать простое промежуточное ПО для определения конфигурации и пользовательской версии

    app.use( function( req, res, next ){
      //If were not on an authenticated route
      if( ! req.user ){
        next();
        return;
      }
      //retrieving the user info will be server dependent
      if( req.user.schemaVersion === app.get('schemaVersion')){
        next();
        return;
      }
    
      //handle upgrade if user version is less than app version
    
      //handle downgrade if user version is greater than app version
    
      //save the user version to your session / auth token / MongoDB where necessary
    })
    

Для обновления/понижения я сделал бы простые файлы js в каталоге миграций с функциями экспорта/понижения экспорта, которые будут принимать модель пользователя и выполнять изменения миграции для этого конкретного пользователя в MongoDB. Наконец, убедитесь, что версия пользователя обновлена ​​в вашем MongoDB, чтобы они не запускали изменения заново, если они не перейдут в другую версию снова.

Ответ 2

Если вы привыкли к миграции типа SQL или миграции, подобным Rails, вы найдете мой инструмент cli migrate-mongoose, подходящий для вас.

Он позволяет писать миграции с помощью функции up и down и управляет состоянием для вас на основе успеха и неудачи ваших миграций.

Он также поддерживает ES6, если вы используете синтаксис ES 2015.

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

Ответ 3

Существует 2 типа миграций:

  • В автономном режиме: вам потребуется отказаться от обслуживания для обслуживания, затем перебрать всю коллекцию и внести необходимые изменения.

  • В сети: не требуется снимать ваш сервис для обслуживания. Когда вы читаете документ, вы проверяете его версию и запускаете процедуру миграции для конкретной версии для каждой версии между старым и новым. Затем вы загружаете полученную вещь.

Не все службы могут позволить себе автономную миграцию, я рекомендую онлайн-подход.