Wiele pytań tutaj. Odpowiem na pytania z naciskiem na FluentMigrator.
Czy jest to sposób na początkowe tworzenie, a następnie aktualizowanie bazy danych w drodze kontroli wersji.
FluentMigrator to sposób na kontrolowanie wersji schematu bazy danych. Każdy to robi w jakiś sposób. Ręcznie, za pomocą skryptów sql, z narzędziem takim jak SqlCompare lub projektem bazy danych Visual Studio. Wszystkie te metody są łatwe do zepsucia. Łatwo jest popełnić błąd po wypuszczeniu nowej wersji i spowodować awarię systemu. Migracje to lepszy sposób na poradzenie sobie z tym.
FluentMigrator umożliwia zdefiniowanie zmiany w schemacie jako kodu i jest zwykle sprawdzane w kontrolerze źródłowym przy innych zmianach kodu. Oznacza to, że możesz powiedzieć, że wersja 1.XX twojego systemu powinna mieć wersję 123 bazy danych. Oznacza to, że jeśli przywrócisz swój kod do poprzedniej wersji, wiesz również, do której wersji bazy danych również chcesz przywrócić.
Może być używany zarówno do tworzenia schematu bazy danych od samego początku, jak i do uruchamiania z kontrolą wersji schematu dla istniejącej bazy danych.
Migracja to sposób na opisanie zmiany w schemacie bazy danych.FluentMigrator tworzy tabelę VersionInfo i przechowuje unikalny identyfikator (numer wersji) migracji po zastosowaniu.
Na przykład, jeśli mam dwie migracje jedną z Id 1 i jedną z Id 2. Jeśli wtedy wykonam pierwszą migrację, to Id 1 zostanie zapisana w tabeli VersionInfo i mogę tam spojrzeć i wiem, że wersja baza danych to 1 i ta wersja 2 nie została jeszcze zastosowana.
Możliwość rozpoznania, która wersja schematu bazy danych jest bardzo przydatna podczas przesyłania zmian z testu do wersji produkcyjnej lub w przypadku wielu kopii bazy danych w wersji produkcyjnej. Na przykład mam klienta z biurami na całym świecie, a każde biuro ma własną kopię bazy danych i wszystkie są w różnych wersjach. Bez znajomości wersji bazy danych bardzo trudno byłoby je zaktualizować w bezpieczny sposób.
W większości przypadków nie muszę zaglądać do tabeli VersionInfo, FluentMigrator obsługuje to automatycznie. Porównuje zestawienie z Migracjami do tabeli VersionInfo i określa, które zmiany nie zostały jeszcze zastosowane, a następnie wykonuje je.
Pierwsza migracja (lub początkowa wersja bazy danych) będzie zawierać wszystkie tabele, relacje i właściwości wymagane (zrobione albo płynnie lub za pomocą kawałek sql w skrypcie).
Punkt wyjścia należy do Ciebie. Możesz przeprowadzić pierwszą migrację, która jest skryptem sql wygenerowanym z bieżącej bazy danych. Można również użyć jednego z projektów contrib, takich jak , aby wygenerować płynną migrację. Lub możesz po prostu zdecydować, że istniejąca baza danych jest punktem wyjścia i zapisać jej kopię, aby móc przywrócić ją jako wersję 1.
Wprowadziłem FluentMigrator do wielu starszych baz danych bez większych problemów.
Gdy chcesz pchania zmiany do bazy danych, należy utworzyć nowy metodę migracji (góra i dół), coś dodać nową tabelę lub zmodyfikować pole.
Tak, W górę służy do zastosowania zmiany określonej w Migracji i w dół powoduje jej wycofanie. Tak więc może być tworzenie tabeli, a Down może być upuszczeniem stołu.
Aby wdrożyć jedną z tych migracji, należy użyć wiersza polecenia określającą dll zawierającego migracji ciąg połączenia i wymagana wersja. Dostępne są trzy runners do wykonania migracji. Runner wiersza poleceń, zadanie Nant i zadanie MSBuild. Zwykle są wykonywane jako część skryptu budowania.
Klasa MigrationRunner może być również używana w kodzie. Możesz to zrobić, jeśli chcesz zbudować własnego runnera lub jeśli masz inne potrzeby (np. Dynamiczne budowanie baz danych lub automatyczne aktualizowanie bazy danych po dodaniu nowej migracji).
Jeśli miałeś dość złożony zestaw modele danych, czy nie byłoby trudne i czasochłonne stworzenie definicji migracji dla wszystkich?
Większość już odpowiedziałem na to. Zwykle dość łatwo jest wygenerować skrypt SQL dla bazy danych. W przypadku serwera Sql wygenerowanie skryptu zajmuje mniej niż minutę, nawet w przypadku dużych baz danych. Skrypt ten można zapisać w pliku .sql i wykonać jako pierwszą migrację przy użyciu wyrażenia Execute.EmbeddedSqlScript. To działa przyjemność.
wiem z NHibernate/Fluent można łatwo wygenerować tabele do bazy danych bez konieczności definiowania czegokolwiek innego niż modeli i plików map. Czy istnieje sposób na dostosowanie tej konfiguracji do wersji Migrator/Versioning?
W tej chwili nie ma takiej integracji, aw praktyce przynajmniej jej nie przeoczę. Było trochę dyskusji na temat połączenia Fluent NHibernate i FluentMigrator, ale byłoby to dużo pracy. Pozwoliłoby to rusztowaniom generować zmiany w modelu takim jak kod EF. Nie jest to jednak w tej chwili plan działania.
nie Kiedy NHibernate/Fluent jest odpowiedzialny za generowanie bazy danych, mam koniecznie trzeba zdefiniować każdy aspekt rzeczą stołach. Wykonuje się je poprzez konwencję lub pliki mapujące. Z migrantami I musiałbym zdefiniować ten poziom szczegółowości?
Tak, należy określić na tym poziomie szczegółowości. Migracje FluentMigrators są DSL (własnym małym językiem) do definiowania zmian w schemacie, które są tłumaczone na sql. Możesz również napisać sql bezpośrednio używając wyrażenia Execute.Sql. Migracje Entity Frameworks mają tego rodzaju integrację, która ma zarówno zalety, jak i wady.
Zapoznaj się z wiki lub jeden z tutoriali here, here (część 1) lub here (część 2), aby uzyskać pomoc podręczny.