...
Dostępne są migracje konfiguracji:
- sowas - migracja konfiguracji dostępnych serwisów (przejęcie kontroli nad konfiguracją sowas.cfg)
- sowa2 - migracja konfiguracji zainstalowanych serwisów typu SOWA2 (przejęcie kontroli nad plikiem .inf, katalog.ini oraz index.py)
- sowasql - migracja konfiguracji zainstalowanych serwisów typu SOWASQL (przejęcie kontroli nad całym katalogiem etc/)
Składnia
| Code Block |
|---|
sowizor migrate sowas [check|start] [--force] sowa2|sowasql sowizor migrate sowa2|<sid> [--force] [--nodelete] [--ignore-params|--generate-params] [--generate-services] [--use=-schema=<hid>] [--override-records] |
Migracja konfiguracji
...
W systemach Linux instalowany jest moduł o nazwie "sowas". Konfiguracja katalogów SOWY przechowywana jest w pliku sowas.cfg. Podczas migracji sowizor przejmuje kontrolę nad tym plikiem - od momentu migracji jest on automatycznie generowany podczas wszelkich operacji na serwisach dokonywanych przy pomocy sowizora.
Migracja konfiguracji sowas jest obligatoryjna i należy ją przeprowadzić zaraz po instalacji sowizora.
Wywołanie polecenia z parametrem sowas lub sowas check - weryfikuje możliwość migracji ustawień (zwykle nie ma z tym problemu).
Wywołanie polecenia z parametrem sowas start - przeprowadza migrację konfiguracji. Od tego momentu serwisy są już pod kontrolą sowizora (nie ma potrzeby uruchamiania polecenia "scan").
Operację tę należy wykonać tylko raz. Jeśli z jakiegoś powodu zaistnieje konieczność jej powtórzenia, konieczne będzie podanie opcjonalnego atrybutu --force. Wymusi to ponowną migrację konfiguracji z pliku sowas.cfg.
Migracja konfiguracji serwisów SOWA2
...
serwisów SOWA2 i SOWASQL
Wydając polecenie z parametrem sowa2 lub sowasql można wyświetlić listę serwisów, potencjalnie nadających się do migracji.
Podając jako parametr identyfikator <sid> uruchamia się migrację serwisu (o ile jest to serwis SOWA2 lub SOWASQL).
Jest to zaawansowany, skomplikowany proces, który wymaga szczegółowej wiedzy na temat architektury systemu i sposobu jego konfiguracji. Z tego powodu wskazane jest przeprowadzanie tej operacji pod nadzorem pracowników firmy SOKRATES-software.
...
- detekcja schematu (schemat określa przeznaczenie serwisu, układ katalogu, dostępne rekordy i bazy aplikacji)
- detekcja używanych typów rekordów
- wykrycie różnic w konfiguracji pól logicznych rekordów SOWY2
- sprawdzenie poprawności parametrów systemu
- wykrycie używanych usług katalogu SOWY2 (detekcja m.in. formatów, zestawień, programów, indeksów, kryteriów itd.)
- sprawdzenie dostępności i poprawności struktur plików DBF (nie dotyczy wersji SQL)
Po zakończeniu fazy check, program dla każdego migrowanego serwisu wyświetli podsumowanie i możliwe dalsze kroki migracji. Możliwe są następujące statusy:
...
Proces ten archiwizuje dotychczasowe ustawienia, dzięki czemu można w razie potrzeby odzyskać starą konfigurację. Domyślnie jest ona archiwizowana i usuwana. Można to zmienić dzięki opcji --nodelete - podanie jej spowoduje, że dotychczasowa konfiguracja nie zostanie usunięta, lecz tylko zostaną przemianowane pliki na rozszerzenie .old.
...
Zmiana bazowego schematu serwisu
Polecenie migrate służy także do zmiany bazowego schematu serwisu. W ten sposób można np. rozszerzyć funkcjonalność serwisu - do serwisu obsługującego katalogowanie MARC21 dołożyć typy rekordów i programy dla zasobów czasopism, albo np. do akcesji zbiorów. W szczególności należy jednak pamiętać, że jedyne bezpieczne migracje wykonuje się od schematu węższego do szerszego. "Obcinanie" funkcjonalności (czyli np. usuwanie akcesji) wymaga wcześniejszego zweryfikowania, że dla usuwanych typów rekordów nie ma żadnych danych w bazie.
Operacja zmiany schematu bazowego jest oparta na tych samych mechanizmach, co zwykła migracja. Wymagane jest jedynie użycie parametru --use-schema=<hid>. Listę dostępnych schematów można zobaczyć w dokumentacji polecenia add.
| Code Block | ||
|---|---|---|
| ||
sowizor migrate biblioteka_pub_ks start --use-schema=marc21-zasob |