Nie ma w tym nic wbudowanego. To, co zrobiłem na razie, jest podobne do działania Rails, ale jako część uruchamiania zamiast oddzielnego zadania. Najpierw utwórz plik Meteor.Collection
o nazwie Migracje, a następnie dla każdej dyskretnej migracji utwórz funkcję w podkatalogu server
uruchamianym podczas uruchamiania. Powinien uruchamiać migrację tylko wtedy, gdy jeszcze nie był uruchamiany i powinien oznaczyć migrację w kolekcji Migracje po jej zakończeniu.
// database migrations
Migrations = new Meteor.Collection('migrations');
Meteor.startup(function() {
if (!Migrations.findOne({name: "addFullName"})) {
Users.find().forEach(function (user) {
Users.update(user._id, {$set: {fullname: users.firstname + ' ' + users.lastname}});
});
Migrations.insert({name: "addFullName"});
}
});
Można rozszerzyć tę technikę do wsparcia w dół migracje (poszukaj istnienia danej migracji i odwrócić go), wymusić porządek na migracje i podzielić każdy migrację do osobnego pliku, jeśli chciałeś.
Warto pomyśleć o inteligentnym pakiecie do automatyzacji tego.
Mogę ewentualnie uzyskać motywację do zrobienia inteligentnego pakietu z tą logiką. To wciąż lepsze niż niejasna metoda meteorytów. – wizonesolutions
Jeśli masz więcej niż jeden serwer działający na tej samej bazie danych (wiele serwerów sieciowych lub mikroserwisów), możesz napotkać problemy, gdy wszystkie 5 serwerów uruchomi to samo zapytanie. Ten pakiet wydaje się używać [mechanizmu blokującego] (https://github.com/percolatestudio/meteor-migrations/blob/master/migrations_server.js#L159) –