Metody zwracające obiekt który usunęły

0

Hej, czasami zdarza mi się spotkać kod który usuwa obiekt np z bazy danych(wiadomo zmiana flagi) i jednocześnie zwraca ten obiekt lub jego ID.

public Model removeModelById(ModelId id);

Zawsze zastanawiam się skąd bierze się taki pomysł.
Osobiście preferuje zwracanie optionala z błędem w sytuacji kiedy coś poszło nie tak (Nie można usunąć/ Model nie istnieje).

public Optional<ModelServiceError> removeModelById(ModelId id);

Dlaczego metoda remove(Id id) miała by zwracać obiekt który usunęła i który już nie istnieje.

W jakich przypadkach lub jaki jest sens zwracanie usuniętego obiektu lub jego id?

1

Jeśli ten Model byłby w oparciu o jakiś Optional<> ...

Generalnie spójrz szerzej, jest napięcie pomiedzy ujęciem obiektowym a relacyjnym, to jest teoretycznie analizowane itd, ze względów zasadniczych tego nie da się idealnie skonstruować.
To, co podnosisz, jest jakby jeszcze innym aspektem, mniej analizowany a BARDZO ciekawym

(Tak, o dobrym/złym kasowaniu w złożonym systemie można mówić sto lat)

0

@ZrobieDobrze: taaak taaak też o tym czytałem xd.

1

ja bym wolał booleana zwracać

2
krancki napisał(a):

Dlaczego metoda remove(Id id) miała by zwracać obiekt który usunęła i który już nie istnieje.

może ktoś się niepotrzebnie wzoruje na metodach ze standardowych kolekcji, np: https://docs.oracle.com/javase/8/docs/api/java/util/List.html#remove-int- ?

1

Po co remove miałoby zwracać cokolwiek? To chyba użytkownik powinien najpierw się upewnić czy coś istnieje i dopiero usuwać. Przy dzieleniu też miałbym zwracać optionala za każdym razem bo ktoś może podać 0? Sprawdzanie i usuwanie to dwie różne czynności. Jak już iść w tym kierunku to chociaż nazwać metodę removeIfExists która usuwa coś jeśli istnieje i nie robi nic w przypadku przeciwnym.

Jak mam metodę do usuwania to raczej chce wiedzieć że po jej wykonaniu nie będzie rekordu w bazie, a nie obsługiwać sytuację kiedy go nie ma.
Jak chce wiedzieć czy coś istnieje w bazie to wywołałbym metodę exists i obsłużył sytuację gdy czegoś nie ma w bazie.

2

To be clear. Jeżeli ktoś usuwa obiekt który już nie istnieje i dostaje ten obiekt - to jest błąd.

Jeżeli remove usuwa obiekt i go zwraca to nie ma tu separacji mutacja/odczyt, ale wykonujesz jedno zapytanie a nie 2. Argument optymalizacyjny, pytanie ile requestow na sekundę oszczędzisz. Jeżeli milion to może warto.

Ważne żeby zrobić CDD i umówić sie miedzy dwoma stronami jak pracujemy.

1
DKN napisał(a):

To be clear. Jeżeli ktoś usuwa obiekt który już nie istnieje i dostaje ten obiekt - to jest błąd.

Jeżeli remove usuwa obiekt i go zwraca to nie ma tu separacji mutacja/odczyt, ale wykonujesz jedno zapytanie a nie 2. Argument optymalizacyjny, pytanie ile requestow na sekundę oszczędzisz. Jeżeli milion to może warto.

Ważne żeby zrobić CDD i umówić sie miedzy dwoma stronami jak pracujemy.

Czekaj czekaj. Usuwasz obiekt i zwracasz co? Obiekt sprzed usunięcia? Po co takie coś zwracać w ogóle skoro wcześniej już go masz? Referencje, id? Przecież to wszystko masz przed usunięciem. Nie rozuiem po co ktoś miałby usuwać coś z bazy i próbować to od razu odczytywać więc o jaką optymalizacje chodzi :D

JEŚLI usunięcie polega na zmianie statusu to chyba jak rozumiem jest to update obiektu a nie usunięcie? Wtedy jak mniemam metoda nie powinna nazywać się remove przynajmniej nie na poziomie jakiegoś repo gdzie leci sql tylko update.

1

Chyba się nie spotkałem z takim rozwiązaniem, na myśl przychodzą mi 2 kejsy:

  1. Zamiast fizycznego usunięcia obiektu przestawiamy mu jakiś status/flagę i taki zmieniony obiekt zwracamy. Może ktoś potem gdzieś potrzebuje tego statusu 🤷🏻‍♂️
  2. Zwracanie metadanych o usunięciu, np. ile rekordów usunęło query.
2

Optimistic delete - usuwasz, sprawdzasz czy to jest to co chciałeś usunąć i jak nie to dodajesz z powrotem 😎

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