Temat: Integralność bazy danych , a integralność encji.

Ostatnio tak głęboko się zastanawiałem miałem przykładowe 2 encje wyglądało to na coś takiego:

class test {

public List<TestType> testTypes;

}

Natomiast w TestTypes nie było odniesienia do klasy Test. Problem polegał na tym, że w aplikacji ktoś stworzył funkcjonalność umożliwiającą usunięcie tabeli TestType. Całość działała ale tylko wtedy gdy żadna encja Test nie miała odniesienia do TestType. Błąd naprawiłem więc na poziomie bazy danych (postgresql) tj. na w tabeli Test dodałem ON DELETE CASCADE i wszystko zaczęło chulać.

Jednak ktoś zapytał mnie dlaczego do encji TestType nie dodałem zależności do Test (na poziomie encji wiązanie FetchType.Lazy) i nie dałem tam Cascade itd. , argumentując takie rozwiązanie faktem, że lazy załatwia taką sprawę i jpa (toplink) się nie pogubi a do tego zostanie zachowana`Redundancja`.

Zastanawiam się które rozumowanie jest poprawne. Jak dla mnie niepotrzebne jest `obciążanie` encji TestType odwołaniem do Test, a dodawanie tego typu tylko po to żeby zapewnić odpowiednie usuwanie ?? Po drugie wydaje mi się, że zachowanie odpowiedniej spójności na bazie danych to inna sprawa niż aplikacja. Po trzecie przecież JPA sobie powinien poradzić (odpowiednio zinterpretować) ON DELETE CASCADE .....

PS. Spotkałem się z takim rozumowaniem, że jest dobrze aby używać `Redundancji`. Czyli jeśli w encji masz odniesienie typu @OneToMany , @OneToOne itd do innej to niech ta druga encja też posiada odniesienie...
Jak dla mnie jest to kwestia zastanowienia się czy jest taka potrzeba , a nie wszędzie gdzie się da ładować zależności .. Chyba, że się mylę ??Łukasz Woźniczka edytował(a) ten post dnia 16.02.13 o godzinie 12:58

Temat: Integralność bazy danych , a integralność encji.

Dla przykladu Hibernate zaleca uzywanie referencji bi, argumentujac to tym, ze latwiej po nich nawigowac. Swojego czasu dosc nagminnie z nich korzystalem, az pojawil sie problem: optimistic lock exc. Jako ze przy dodawaniu dziecka zmienia sie wersja rodzica, to przy jednoczesnym dodawaniu wielu dzieci pojawil sie problem z OLE. Referencje bi zamienilem na uni, w rodzicach pozostawiajac odpowiednie metody dostepowe i sprawa sie rozwiazala: mialem funkcjonalnosc bi, ale dzialanie uni. W przypadku Hibernate mozna skorzystac z adnotacji OptimisticLock, jednak takie rozwiazanie nie jest JPA friendly :-).
Dodatkowym mankamentem w przypadku bi jest dla mnie koniecznosc ustawiania dwoch stron referencji (p.getChildren().add(c) lacznie z c.setParent(p)). To jednak tez zostalo rozwiazane poprzez odpowiednia implementacje seta i opakowanie listy: nie wazne z ktorej strony programista ustawial powiazanie zawsze druga strona zostala ustawiona. Bylo to o tyle dobre, ze nawet jak ktos zmienil rodzaj ref. z uni na bi lub odwrotnie to nie bylo potrzeby zmiany kodu, jedynie metod dostepowych, z ktorych korzystano.
To samo tyczylo sie delete: programista wolal delete a implementacja metody (tworzona na podstawie modelu danych) usuwala co trzeba (rowniez dzieci z referencji uni, jesli takowe istnialy, a o ktorych nie mozna sie bylo dowiedziec analizujac tylko rodzica).