Historia dla tabel złączeniowych

Moduł umożliwia rejestrację informacji o zmianach danych w tabelach złączeniowych. Do tego celu jest używane pole extra_id w tabeli historii oraz funkcje modułu w wersji posiadającej parametr extraId. Typowo zmiana w tabeli złączeniowej przypisywana jest do jednej z tabel wchodzących w skład złączenia, np. mając tabele A i B oraz tabelę złączeniową A_B, zmianę w tabeli A_B rejestruje się jako przypisaną do tabeli A (lub B), z nazwą tabeli A (lub B) i kolumny nie istniejącej w tabeli A (lub B) tylko w tabeli A_B. Wtedy row_id to klucz główny tabeli A (lub B) a extra_id to klucz główny z drugiej tabeli wchodzącej w skład złączenia: B (lub A).

Rejestracja danych dla tabel złączeniowych najczęściej występuje w dwóch przedstawionych poniżej sytuacjach. Pierwszy przypadek to typowa tabela złączeniowa:

Załóżmy, że istnieje rola o id=7 i przywilej o id=4. Zmiana polegająca na przypisaniu przywileju 4 do roli 7 mogłaby zostać zarejestrowana w historii jako:

$=(@historyId, $history.recordChange("p_roles", "p_priv_id", 7, (String)null, "4", $user.userID(), 4))

lub

$=(@historyId, $history.recordChange("p_privs", "p_role_id", 4, (String)null, "7", $user.userID(), 7))

Wybór wersji należy do projektanta aplikacji, jednakże w tym przypadku pierwsza propozycja wydaje się bardziej logiczna, ponieważ to przywileje są grupowane za pomocą ról a nie na odwrót.

Druga sytuacja, w której możliwe jest wykorzystanie pola extra_id w tabelach historii przedstawiona jest poniżej:

Istnieje tu tabela documents_params, która nie jest typową tabelą złączeniową - posiada własny klucz główny a nie klucz złożony z kluczy głównych tabel nadrzędnych. Logicznie pełni ona jednak rolę tabeli złączeniowej, ale takiej, w której wpisy dotyczące złączenia mogą się powtarzać - w jednym dokumencie można mieć wiele parametrów danego typu z różnymi wartościami. Tabela ta mogłaby więc posiadać własne wpisy w historii, niezależne od tabel nadrzędnych. Można jednak oczekiwać, iż wartości parametrów, jako integralna część dokumentów, będą miały swoją historię związaną z tabelą documents a nie documents_params.

Załóżmy, że w tabeli params_dictionary mamy wpis o id=2, w documents wpis o id=4, a w documents_params wpis o (id=16, document_id=4, params_dictionary_id=2, param_value="ala"). Rejestracja historii dla tego parametru dokumentu w wersji skojarzonej w tabelą documents a nie documents_params może wyglądać następująco:

$=(@historyId, $history.recordChange("documents", "param_value", 4, (String)null, "ala", $user.userID(), 16))

Jeżeli z tabelą podstawową związana jest więcej niż jedna tabela złączeniowa, to sposób rejestracji zmian w tych tabelach powinien zostać ustalony przez osobę piszącą aplikację - można np. w polu column_name zapisywać wartość nazwa_tabeli_złączeniowej#nazwa_kolumny_w_tabeli_złączeniowej zamiast tylko nazwa_kolumny_w_tabeli_złączeniowej.