konta użytkowników a logowanie zmian

Odpowiedz Nowy wątek
2015-02-19 10:23
0

Witam.

Opiszę najpierw projekt (część). Programuję w środowisku NetBeans, baza danych Postgresql 9.4, Hibernate.
Mam powiedzmy 3 tabele w bazie: pracownik, modyfikacja, uzytkownik. W tabeli pracownik są dane osobowe, tabela uzytkownik to dane do logowania (id, login, haslo, imie, nazwisko), tabela modyfikacja jest na potrzeby logowania (zbierania) zmian w tabeli pracownik i zawiera kolumny: id, data, pole, wartosc_przed, wartosc_po, uzytkownik. Czyli tutaj zapisuje się kiedy, z jakiej wartości na jaką zmienił ktoś (użytkownik zalogowany). Zmiany te są do niej wstawiane poprzez trigger na tabeli pracownicy i odpowiedniej funkcji, która wie jakie pole było zmieniane (instrukcje if oraz insert). Natomiast pozostała mi kwestia zalogowanego użytkownika. Aplikacja w Javie jest desktopowa, na początku włącza się okienko logowania, sprawdzany jest login i hasło, jest też możliwość stworzenia nowego konta. To sprawdzanie i zakładanie konta wykorzystuje persistence.xml, w którym "na sztywno" jest wpisane po jakim koncie Postgresql ma się łączyć z bazą. Zalogować też się można ale po tych danych z persistecne.xml.
Jak mam zrobić aby trigger na tabeli pracownicy wiedział jaki user się zalogował (z tabeli uzytkownik) i był wpisany w pole uzytkownik w tabeli modyfikacja? Gdy wpiszę CURRENT_USER w funkcji dla triggera to zawsze będzie to user Postgresql, czyli zawsze ten sam z persistence.xml.
Czy lepiej nie mieć tabeli uzytkownik ale za to tworzyć userów w Postgresql? Tylko wtedy jak robić logowanie do bazy po tym userze jak wykorzystuję persistence.xml, w którym jest wpisany już inny użytkownik?

edytowany 2x, ostatnio: koklowski, 2015-02-19 10:24

Pozostało 580 znaków

2015-02-19 22:17
0

Nazwę użytkownika możesz przechowywać w pamięci programu w miejscu do którego będziesz miał dostęp z każdego miejsca, np. pola statyczne, oczywiście uzupełniane podczas logowania. Do bazy nazwę użytkownika możesz wówczas przesłać za pomocą parametru w instrukcji update, to rozwiązanie wymaga jednak utworzenia dodatkowego pola w tabeli z nazwą usera, który ostatnio modyfikował dany wiersz. Po każdej modyfikacji odpalony zostanie triger uzupełniający dane w historii wraz z danymi o userze.
Nie jest to może idealne rozwiązanie, natomiast 1) zachowasz jednego usera w db, 2)nakład pracy potrzebny by zmodyfikować istniejący program jest niewielki

Pozostało 580 znaków

2015-02-20 08:09
Biały Kot
0

Tak też myślałem ale chciałem to zrobić lepiej :).
Ponadto trigger mi uzupełnia w jakiej konkretnie kolumnie tabeli została zmieniona wartość na jaką. I tak właśnie chcę a nie cały wiersz.
Czekam więc na dalszą pomoc (bardziej chodzi mi o to jak podejść do tematu).

Pozostało 580 znaków

2015-02-20 09:33
0

Ponadto logowanie modyfikowania chcę oddzielić od aplikacji - po to trigger i funkcja na bazie danych.

Pozostało 580 znaków

2015-02-20 11:44
0

Z uwagi ze trigger jest bezparamtertowy po to własne wraz z updatem rekordu info o użytkowniku. Jak najbardziej podejście z wykorzystaniem trigerra jest poprawne

Pozostało 580 znaków

2015-02-20 12:21
0
Biały Kot napisał(a):

Tak też myślałem ale chciałem to zrobić lepiej :).
Ponadto trigger mi uzupełnia w jakiej konkretnie kolumnie tabeli została zmieniona wartość na jaką. I tak właśnie chcę a nie cały wiersz.
Czekam więc na dalszą pomoc (bardziej chodzi mi o to jak podejść do tematu).

Podzielisz sie na forum swoim pomysłem?

Pozostało 580 znaków

2015-02-20 14:29
0

Trigger na tabeli pracownik:

IF OLD.nazwisko != NEW.nazwisko THEN
            insert into modyfikacja(data, pole, wartosc_przed, wartosc_po, uzytkownik) values(LOCALTIMESTAMP, 'nazwisko', OLD.nazwisko, NEW.nazwisko, CURRENT_USER);
END IF;

IF OLD.imie != NEW.imie THEN
            insert into modyfikacja(data, pole, wartosc_przed, wartosc_po, uzytkownik) values(LOCALTIMESTAMP, 'imie', OLD.imie, NEW.imie, CURRENT_USER);
END IF;

I właśnie to CURRENT_USER muszę zmienić.

Pozostało 580 znaków

2015-02-20 14:32
1

Wersjonowanie encji z poziomu Hibernate za pomocą Hibernate Envers> http://docs.jboss.org/envers/docs/index.html
Jeżeli zmiany robisz z poziomu aplikacji to żaden trigger nie jest potrzebny (a nawet szkodliwy, bo wiąże logikę biznesową z bazą na sztywno).

edytowany 1x, ostatnio: Koziołek, 2015-02-20 14:36

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0