Dodawanie Envers do istniejącej bazy danych

Question

Mam aplikację opartą na Hibernate w produkcji, z dużą bazą danych. Muszę dodać audyt do dwóch elementów (dwóch tabel) w tej aplikacji, i zdecydowałem się pójść z Envers.

Dla każdego INSERT, UPDATE lub DELETE, Envers dodaje nowy rekord do tabeli kontroli jednostki.

Gdybym miał wsparcie Envers od uruchomienia aplikacji, tabele kontroli byłyby zapełniane w momencie tworzenia jednostek (INSERT).

Dokumentacja Envers jest bardzo cienka i nie wspomina nic o dodaniu Envers do istniejącej aplikacji.

Jeśli po prostu dodaję obsługę Envers i utworzę odpowiednie tabele audytu, zaczną one być puste, więc kiedy AKTUALIZUJĘ istniejącą encję, Envers doda rekord do tabeli audytu rejestrując nowe wartości, ale stracę poprzednie wartości.

Jak dodać obsługę Envers do aplikacji z istniejącą bazą danych?

Answer 1

Obecnie nie ma wbudowanego rozwiązania.

"Poprawnym" sposobem byłoby napisanie skryptu SQL (lub ręczne utworzenie) wersji "0" wraz z rekordami kontroli wstawiania związanymi z tą wersją dla każdej istniejącej jednostki.

Właściwie jest to dość popularna funkcja, więc jeśli chcesz wnieść swój wkład, byłbyś bardzo mile widziany!

Answer 2

Konieczne będzie ręczne wstawianie. Coś jak

INSERT INTO z_envers_revisions (ID, timestamp, user_id, user_name) values (1, round((sysdate - to_date('19700101','YYYYMMDD')) * 86400000) , 42, 'UserName'); 

INSERT INTO z_Table1(rev, revtype, id, description, name) select 1 as rev, 0 as revtype, id, description, name from Table1; 
INSERT INTO z_Table2(rev, revtype, id, description, name) select 1 as rev, 0 as revtype, id, description, name from Table2; 

Mam prefiksem moje tabel kontrolnych z AZ tutaj, aby go skrócić

Answer 3

miarę envers obawia się, podstawowy przypadek użycia jest nagrywać pełną kontrolę podmiotu (parametry my chcesz przez @Anited adnotation). W przypadku, o którym wspomniałeś, nowe podmioty mogą zostać dodane poprawnie, ale w przypadku istniejącego problemu wystąpiłoby problem, ponieważ w tabeli kontroli nie ma żadnej rewizji.

Załóżmy rozwiązać sprawę z pomocą scenariusza:

Powiedzmy podmiot podjęliśmy pod uwagę to użytkowników. Stół, który powstaje teraz, aby obserwować historię, powiedzmy, jest users_audit. Oprócz tego istnieje również możliwość obserwowania i rejestrowania wszystkich zmian w danym rekordzie, pod numerem revinfo.

Problem jest na pierwszym miejscu, ponieważ w przypadku każdej aktualizacji warstwa trwałości nie może znaleźć rekordu wersji. Aby to naprawić, wszystkie istniejące wpisy muszą znajdować się w tabeli, a odwzorowanie klucza obcego z tabelą revinfo nie powinno się zepsuć. Stąd też, dwie rzeczy muszą być zrobione:

1. Wstawianie wartości tymczasowe w tabeli revinfo tak że rev może pełnić rolę klucza obcego
2. skopiować dane z użytkowników stół do users_audit stół.

Próbka Liquibase pliku może być tak:

CREATE TABLE `revinfo` (
     `rev` int(11) NOT NULL AUTO_INCREMENT, 
     `revtstmp` bigint(20) DEFAULT NULL, 
     PRIMARY KEY (`rev`) 
    ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8; 

    INSERT INTO `revinfo` (`revtstmp`) select updated_at from users u; 

    SET @position := 0; 

    insert into users_audit (
    rev, 
    revtype, 
    id, 
    name, 
    type, 
    mobile_number, 
    password, 
    parent_id, 
    profile_image_uri, 
    is_active, 
    created_at, 
    updated_at 
    ) select @position := @position +1, 0, 
    id, 
    name, 
    type, 
    mobile_number, 
    password, 
    parent_id, 
    profile_image_uri, 
    is_active, 
    created_at, 
    updated_at from us