Przyjmując to i rozsądnie rozumiejąc, jak migracje działają na relacyjnej bazie danych, MongoDB czyni to nieco prostszym. Doszedłem do 2 sposobów, aby to przełamać. Rzeczy do rozważenia przy czynienia z migracją danych w MongoDB (nie wszystkie, które niezbyt często z baz danych tras RDB) są:
- Zapewnienie lokalnych środowisk testowych nie pękają, gdy deweloper łączy najnowszy z repozytorium projektu
- Zapewnienie żadnych danych jest poprawnie aktualizowany w wersji na żywo, niezależnie od tego, czy użytkownik jest zalogowany, czy nie, jeśli używane jest uwierzytelnianie. (Oczywiście, jeśli wszyscy zostaną automatycznie wylogowani po dokonaniu aktualizacji, wtedy tylko martwienie się o to, kiedy użytkownik się zaloguje jest konieczne).
1) Jeśli zmiana spowoduje wylogowanie wszystkich użytkowników lub przestój aplikacji, spodziewany czas przestoju to prosty skrypt do podłączenia do lokalnego lub Live MongoDB i zaktualizowania poprawnych danych. Przykład gdzie nazwa użytkownika zostanie zmieniona z jednym ciągiem do obiektu ze względu i nazwisko (bardzo podstawowy oczywiście i musiałyby zostać wprowadzone do skryptu, aby uruchomić dla wszystkich programistów):
pomocą 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) Chcesz, aby aplikacja wykonywała migrację schematów w górę iw dół w zależności od używanej wersji aplikacji. Będzie to oczywiście mniej obciążające serwer na żywo i nie będzie wymagało przestojów ze względu na aktualizowanie tylko użytkowników, którzy po raz pierwszy używają wersji zmodernizowanych/obniżonych wersji.
Jeśli za pomocą pośredniczącego w Expressjs dla Nodejs:
- Ustaw aplikacja zmienna w skrypcie głównym aplikacji poprzez
app.set('schemaVersion', 1) które zostaną wykorzystane później porównać z wersją schematu użytkowników.
- Teraz upewnij się, że wszystkie schematy użytkownika mają również właściwość schemaVersion, dzięki czemu możemy wykryć zmianę między wersją schematu aplikacji a bieżącymi schematami MongoDB dla TYLKO DLA użytkownika SZCZEGÓLNEGO.
Następnie musimy stworzyć prosty middleware do wykrywania wersji config i Obsługi
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
})
za upgrade/downgrade chciałbym zrobić proste pliki js pod katalogiem migracje z upgrade/downgrade funkcji eksportowych zaakceptuje model użytkownika i uruchomi zmiany migracji na tym konkretnym użytkowniku w MongoDB. Na koniec upewnij się, że wersja użytkowników jest aktualizowana na MongoDB, aby ponownie nie wprowadzać zmian, chyba że ponownie przejdą do innej wersji.
Witam, udało Ci się rozwiązać ten problem. Połączyłem się z MongoDB za pomocą mangusty i nie chciałem wykonywać migracji. – Xdrone
Przedstawiłem prosty przykład, w którym logika działa w środowisku lokalnym/na żywo. –