Wystarczy podać nieco więcej kontekstu na pytanie, mam aplikację internetową (asp mvc), która zasadniczo opakowuje operacje CRUD do instancji MongoDb, przeprowadza walidację i pewną logikę biznesową, zanim model zostanie zweryfikowany i wysłany do przechowywania, odzyskania itp.Obsługa migracji z MongoDb
Teraz mamy jeden problem, że w nowej wersji modele się zmieniły, ale istniejące dane nie, oto przykład: (jest to C# specyficzne, ale pytanie naprawdę jest agnostyczny)
public class Person
{
public Guid Id {get; set;}
public string Name {get; set;}
public int Age {get;set;}
public string BadgeNo {get;set;}
}
public class Person
{
public Guid Id {get; set;}
public string Name {get; set;}
public int Age {get;set;}
public string EmployeeNo {get; set;} // Still contains same data as BadgeNo just called something different
}
Jak widać struktura obiektów uległa zmianie, ale w kraju Mongo t nadal przekazuje BadgeNo, a nie EmployeeNo. W środowisku SQL zwykle mamy skrypt migracji uruchamiany jako część skryptu budowania, który zmieniałby schemat i aktualizował/wstawiał/usuwał wszelkie dodatkowe dane dla tej delty.
Więc jak najlepiej zarządzać tego rodzaju migracji z Mongo? Czy powinienem mieć również skrypt, którego używam do aktualizowania wszystkich instancji w Mongo? czy jest jakaś inna preferowana praktyka do robienia tego rodzaju rzeczy.
Wszelkie porady na ten temat byłoby świetnie
=== Edit ===
Wydaje się, że obecnie jestem chcąc iść z możliwością migracji zamiast podejścia stopniowego wycofywania, więc z tego Każdy może polecić jakiekolwiek narzędzia pomagające w tej dziedzinie, ponieważ w przeciwnym wypadku każda migracja (zakładając roll-in, roll-out) musiałaby być wcześniej skompilowanym zbiorem z całą logiką. Myślałem o czymś linie FluentMigrator, ale zamiast pracy z SQL pracujesz z Mongo. Obecnie moje skrypty kompilacji używają Nant, widziałem kilka narzędzi ruby, ale nie jestem pewien, czy istnieje jakiś odpowiednik .net.
Wybrałabym opcję 1 - a następnie użyłabym tego kodu, aby utworzyć narzędzie migracji (na przykład z poziomu wiersza poleceń), które później wykonuje równoważnik opcji 2, ładując i zapisując wszystkie dokumenty z kolekcji, które wciąż znajdują się w stara wersja. –
Dobry pomysł Sean, zaktualizowałem swoją odpowiedź. – Derick
Problem polega na tym, że piszesz ALOT z nadmiarem kodu, który będziesz musiał utrzymywać, aby obsługiwać tylko wiele wersji, i wyobrażasz sobie 20 wersji z rzędu, że masz 20 plików dla każdego modelu, który się zmienił. Dla mnie 2 opcje wydają się lepsze, ponieważ łatwiej jest je przenosić między wersjami (tj. Wycofywanie zmian), nie mam problemu z niewielkimi przestojami. Dzięki za odpowiedź pozostawi to nieco dłużej, ponieważ oczekiwałem, że wiele osób powie Opcję 2, ale liczyło na trochę więcej informacji na temat tego, jak najlepiej zautomatyzować drugie podejście, czyli w ramach skryptu budującego. – Grofit