Dziwny PutMapping z nullem plus pytania ala CRUD

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:
@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:
@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

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ł.

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.

18
Optional<Task> update(@RequestBody Task task, @PathVariable int id) {
    [...]
    return null;
}

evilest

2

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

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.

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