Sytuacja: User tworzy sobie obiekt, jest z nią w relacji jeden do wielu, ten obiekt ma kolejne relacje do innych encji, powiedzmy ze tez jeden do wielu, wszystko to wypełnia user (taki formularz). User nie może zapisac tego, a musi wyslac Requesta do admina z tymi danymi zeby on to zrobil. Pytanie, w jaki sposob mozemy przeslac te wszystkie dane do admina bez zapisywania ich? Czy moze uprzedni zapis jest niezbedny i ratowac moze tylko ustawienie typu active:false? Podczas przesylania Requestu do Admina nie mozemy przekazac mu wszystkich obiektow do zapisu, poniewaz nie wiemy ile obiektow bedzie chcial przesłać User. Jest na to jakis sposob? przepraszam, za takie zakrecone tlumaczenie
SQL 
Spring 
Java 
- Rejestracja:prawie 7 lat
- Ostatnio:5 dni
- Lokalizacja:Kraków
- Postów:1999
2
A niby jak miałby wysłać dane z formularza do admina? E-mailem, żeby je wprowadził u siebie i przyklepał? O.o Żeby zmiany, które chce wprowadzić użytkownik mogły być w ogóle widoczne dla kogoś innego - np. administratora, który przyklepuje zmiany - muszą zostać gdzieś zapisane, czyli jakoś musi się zmienić stan aplikacji. Nie zrobisz czegoś takiego bez jakiegoś zapisu gdziekolwiek - nawet, jeśli nie nastąpi od razu w docelowym miejscu, w którym powinny się te dane znaleźć.
Jak chcesz, żeby jakieś zmiany w danych nie były widoczne, dopóki admin ich nie przyklepie, to chyba nie masz wyjścia - musisz albo dorzucić jakąś flagę, czy zapis został zatwierdzony - ale wtedy co będzie, jeśli ktoś będzie chciał jedynie dokonać edycji istniejącego rekordu? Gdzie będzie trzymana poprzednia, zatwierdzona wersja po jej nadpisaniu? Dlatego takie rozwiązanie jest wg. mnie akceptowalne tylko, jeżeli użytkownicy mogą wprowadzać nowe dane i nie mogą edytować poprzednich (co znowu nie ma wiele sensu) - w przeciwnym razie spowoduje same problemy.
Możesz też jakoś na boku kolejkować takie żądania np. w dedykowanej, pomocniczej tabeli lub tabelach - ominiesz nadpisanie zatwierdzonych danych niezatwierdzonymi zmianami i przy okazji rozwiążesz problem żądania wielu zmian naraz tych samych danych przez różnych użytkowników. Inna sprawa to zaprojektowanie tych tabel pomocniczych np. czy mają mieć powielone kolumny danej tabeli (trzeba będzie utrzymywać dodatkową tabelę na każdą istniejącą i pilnować kompatybilności - to może być upierdliwe) czy może żądanie zmian (pierwsza tabela pomocnicza) będzie dotyczyło szeregu dowolnych zmian z informacją której tabeli, którego rekordu i której kolumny itd. dotyczy dana zmiana (druga tabela pomocnicza) - tylko tu znowu dochodzi Ci kłopot w postaci potencjalnie przeinżynierowanego, mocno "generycznego" rozwiązania, które będzie dość skomplikowane w działaniu, potencjalnie może być mniej stabilne i być źródłem różnych dziwacznych corner case'ów i bugów w przyszłości.
edytowany 1x, ostatnio: superdurszlak
Zobacz pozostały 1 komentarz
superdurszlak
... a potem okaże się, że user jednak może chcieć coś edytować i rozwiązanie z flagą idzie w p.... :P
WeiXiao
@superdurszlak: dlaczego? nikt nie broni userowi aby widział requesty, które jego oraz są accepted / awaiting
superdurszlak
No zależy gdzie wyląduje taka flaga, OP podał tak bogate szczegóły, że przez dobrą chwilę zastanawiałem się co właściwie chciał tym osiągnąć. Jak zrobi sobie jakiś taki Request i tam flagę, to to będzie w zasadzie równoznaczne z "pomocniczymi tabelami" w tej czy innej postaci, to jak to nazwie to już inna broszka. Jak będzie chciał trzymać flagę przy rekordzie... no to lipa :D
WeiXiao
@superdurszlak: no jak lipa? powiedzmy, że masz jakiś listing requestów - select request where author.id = your id || accepted = true. i w ten sposób awaiting są niewidoczne, ale edytowalne dla autora.
superdurszlak
No spoko, ale jak ktoś edytuje już zatwierdzony request to albo będą zmiany nieautoryzowane przez admina a widoczne dla wszystkich, albo wersja uprzednio zatwierdzona przepadnie, a pozostali użytkownicy nie będą widzieć żadnej treści do momentu ich ponownego zatwierdzenia i tak czy tak może wyjść bajzel :p szczególnie że z tego co rozumiem zmieniane są różne powiązane dane - i teraz co, jeśli zatwierdzony rekord odnosi się do rekordu z innej tabeli, który ktoś zmienił i już nie jest zatwierdzony? :) dlatego wolałbym mieć żądania osobno, zatwierdzone dane osobno.