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
0
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.
0
Dziękuje bardzo za wyczerpującą odpowiedź :) tak też myślalem ale widzac jak szeroko rozwiniete jest programowanie mialem nadzieje ze jest na to lepszy sposob :D