Dziwny PutMapping z nullem plus pytania ala CRUD

Dziwny PutMapping z nullem plus pytania ala CRUD
TheLearner
  • Rejestracja:ponad 5 lat
  • Ostatnio:około 3 lata
  • Lokalizacja:Krypton
  • Postów:298
0

Stawiam w wolnym czasie pierwsze kroki w Crudach z ciekawości. Staram się omijać (na ile to możliwe) tutoriale, bo jak sam odkrywam to szybciej rozumiem co i jak na dłuższą metę. Przedstawiam następujące wątpliwości i pytania:

  1. Typowy TO DO Crud. Task ma wartość boolean, oznaczającą, że jest albo wykonany, albo nie. Podczas tworzenia Tasku wiadomo, że jest false, ale gdy zostanie wykonany powinno wskakiwać na true. Po tym jak wskoczy na true, taki Task na liście nie jest mi więcej potrzebny, a więc go usuwam. Mimo to, zastosowałem to w PutMapping:
Kopiuj
@DeleteMapping("/task/{id}")
    void deleteTask(@PathVariable int id) {
        taskRepository.deleteById(id);
    }

    @PutMapping("/task/{id}")
    Optional<Task> update(@RequestBody Task task, @PathVariable int id) {
        if (task.isDone() == false) {
            return taskRepository.findById(id)
                    .map(someTask -> {
                        someTask.setDone(task.isDone());
                        someTask.setToDo(task.getToDo());
                        return taskRepository.save(someTask);
                    });
        }else{
            deleteTask(id);
        }
        return null;
    }

No niby działa, ale już pomijając, że się naczytałem, że null się nie wstawia, to cały czas mnie coś puka po głowie, że to nie może tak być. Nie mam również osobnej klasy Service, robię wszystko w kontrolerze.
Moje pytanie więc brzmi, czy to tak może być? I co z tym nullem?

  1. Kolejne pytanie odnośnie id tasku:
Kopiuj
@Entity
public class Task {
    @Id
    @GeneratedValue(strategy= GenerationType.AUTO)
    private int id;
    private String toDo;
    private boolean done;

Na tutorialach (tak, omijam jak się da :) ) id jest zawsze reprezentowane jako Long, ewentualnie spotkałem Integer. Czemu? Nie rozumiem tego, więc używam typ prosty int.
Po drugie, gdy używam PutMapping z punktu 1 z wartością true, usuwa mi się task. Następnie Post Mapping tworzy nowy task, następne id. Czy można tak ustawić GeneratedValue, żeby PostMapping nowy task wstawiał w miejsce id usuniętego?

Więcej grzechów już nie pamiętam


edytowany 1x, ostatnio: TheLearner
MrMadMatt
  • Rejestracja:ponad 9 lat
  • Ostatnio:9 dni
  • Postów:373
2
TheLearner napisał(a):

No niby działa, ale już pomijając, że się naczytałem, że null się nie wstawia, to cały czas mnie coś puka po głowie, że to nie może tak być. Nie mam również osobnej klasy Service, robię wszystko w kontrolerze.
Moje pytanie więc brzmi, czy to tak może być? I co z tym nullem?

Moim zdaniem to zwracanie nulla jest słabe. Z kontrolerów springowych zwracałbym EntityResponse a nie jakieś Taski

Na tutorialach (tak, omijam jak się da :) ) id jest zawsze reprezentowane jako Long, ewentualnie spotkałem Integer. Czemu? Nie rozumiem tego, więc używam typ prosty int.

Bo mały int nie potrafi być nullem, nie w całym okresie życia encji będziesz miał określone ID a wstawianie atrap/fałszywych wartości jest bez sensu.

Po drugie, gdy używam PutMapping z punktu 1 z wartością true, usuwa mi się task. Następnie Post Mapping tworzy nowy task, następne id. Czy można tak ustawić GeneratedValue, żeby PostMapping nowy task wstawiał w miejsce id usuniętego?

To jest jak dla mnie lipny przekombinowany pomysł.

PI
  • Rejestracja:ponad 9 lat
  • Ostatnio:4 miesiące
  • Postów:2787
1
MrMadMatt napisał(a):
TheLearner napisał(a):

Po drugie, gdy używam PutMapping z punktu 1 z wartością true, usuwa mi się task. Następnie Post Mapping tworzy nowy task, następne id. Czy można tak ustawić GeneratedValue, żeby PostMapping nowy task wstawiał w miejsce id usuniętego?

To jest jak dla mnie lipny przekombinowany pomysł.

Dokładnie - nie ma co się silić z tym żeby nie było "gapy" / "przerwy" pomiędzy idkami - jak masz Long id to nawet jakbyś wstawiał rekordy non stop, przez dziesiątki lat, to dalej nie przekroczysz zakresu.

MrMadMatt
Można też dorzucić że jakby autor wątku robił historię rekordu to takie fikołki mocno by mu na-komplikowały obsługę historii zmian na encji biznesowej która jest zapisywana w takim rekordzie.
jarekr000000
To jest też problem bezpieczeństwa, można przypadkiem doprowadzić do sytuacji, gdy związkiem zostaną powiązane rekordy, które nie powinny być (własnie przez jakąś historie). Albo nowy użytkownik zaloguje sie i zobaczy dane starego użytkownika...
jarekr000000
  • Rejestracja:ponad 8 lat
  • Ostatnio:37 minut
  • Lokalizacja:U krasnoludów - pod górą
  • Postów:4707
18
Kopiuj
Optional<Task> update(@RequestBody Task task, @PathVariable int id) {
    [...]
    return null;
}

evilest


jeden i pół terabajta powinno wystarczyć każdemu
Charles_Ray
Wyglada jak podanie o zwolnienie :)
TheLearner
TheLearner
Ja rozumiem, że dla was to oczywiste, ale fajnie jakby ktoś dla mnie rozwinął tą myśl:) po to to wstawiłem w końcu żeby się uczyć :)
jarekr000000
Rozwijam - po to jest optional, żeby nie było null. Jak już zwracasz Optional to właściwą wartością na nie jest Optional.empty(). return Optional.empty()
SL
Normalnie w javie wszystko może być nullem. To powoduje, że powinieneś obsługiwać nulla, tam gdzie go nie ma, a w efekcie kończy się tym, że nie obsługujesz nulla tam gdzie on jest. Optional został wprowadzony, żeby użytkownik metody wiedział, że na 100% ma się spodziewać wartości pustej. Niestety w javie dalej wszystko może być nullem, nawet Optional, więc istnieje złota zasada, że referencja do Optionala zawsze wskazuje na jakiś obiekt.
TheLearner
TheLearner
Dzięki. Następnym razem przeczytam całą dokumentację zanim użyję :)
Shalom
  • Rejestracja:około 21 lat
  • Ostatnio:prawie 3 lata
  • Lokalizacja:Space: the final frontier
  • Postów:26433
2

Powinno byc ResponseEntity<Task> które ładnie się komponuje z optionalem i robi 404 jak jest empty.


"Nie brookliński most, ale przemienić w jasny, nowy dzień najsmutniejszą noc - to jest dopiero coś!"
edytowany 1x, ostatnio: Shalom
nowyworek
ResponseEntity*
Shalom
Oj tam no właśnie ;) każdy wie o co chodzi
EZ
  • Rejestracja:około 5 lat
  • Ostatnio:ponad 4 lata
  • Postów:32
1

To co zrobiłeś bardziej wygląda jak usługa pełniąca rolę kontrolera niż odwrotnie. W parametrach metody i typie zwracanym powinieneś używać dto zamiast encji, np. przekazujesz cały Task jako argument metody, a używasz tylko dwóch właściwości. Nazwa metody "update" w typ przypadku nie jest najlepsza bo aktualizuje encję tylko jeśli task.isDone() == false, zamieniłbym to na dwie metody, np. updateToDo() i completeTask(). Co do id to jak kolega napisał wyżej, czasami to baza danych zajmuje się generowaniem id więc do momentu pierwszego zapisu ma wartość null.

TheLearner
TheLearner
tak zrobię!

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.