PUT a zapis do bazy danych

0

Mam takie pytanie. Tworzę rest API gdzie Encja ma pola:
id
name
age
salary

Tworzę DTO w który podaję
id
age
salary

Encję zapisuję do BAZY DANYCH a metodą GET wyciągam z bazy i od razu jest przemapowane na DTO i w takim formacie (czyli bez name) dostaję ale w bazie danych jest name. Jest wszystko ok, tylko że jak używam metody PUT, ustawiam dwa pola: id do zmiany i np. salary zmieniam. I robię PUT to w bazie danych zmienia się salary tak jak chciałem a reszta (poza id) wskakuje na null. Jak tego uniknąć? Czy za każdym razem w PUT trzeba podawać wszystkie dane i zmieniac te które się chce?
Chcę po prostu mieć w bazie danych pełne informacje jakie zapisuję z encji a metodą PUT np. zmienić tylko salary a żeby reszta w bazie danych pozostała bez zmian.

2

Baza danych udostępnia restowe API?

1

Cześć, wrzuć kod, z którym masz problem

1

@Java91:

Na poziomie "słów" HTTP

ortodoksyjne PUT zakłada, ze jest zasilany pełnym obiektem - alternatywą o jakiej być może myślisz jest PATCH, ale to z wielu powodów nie jest lubiane (jest znacznie trudniejsze w programowaniu obiektowym)

Czegoś nie rozumiem.
Wyprodukowałeś DTO od backendu do frontendu, poleciało, wraca inne DTO f->b. Do tej pory się rozumiemy.

Na poziomie konstrukcji całego systemu / bazy danych

tego DTO z oczywistych względów nie pchasz do bazy bo jest DTO, ale odszukujesz właściwą encję biznesową / bazodanową, i do niej przenosisz wybrane pola (bo wiesz, które to DTO).
Przy okazji, skoro jest ten "drugi" odczyt encji, można zrealizować "optimistic locking"

Podsumowując: masz problem, bo właśnie mało wyraziście rozróżniasz / separujesz encję i DTO. To się głęboko rózni jak nad tym pomedytować

1
Java91 napisał(a):

Tworzę rest API:

Jeżeli tworzysz REST API i robisz to świadomie, to PUT odpowiada za update(upsert). Podręcznikowym zachowaniem jest zamiana wszystkiego co już masz zapisane pod konkretnym id (btw. pole id w DTO nie wróży dobrze), na coś co zostało wysłane.
Możesz albo jak to określa chyba @ZrobieDobrze "zgwałcić REST" i dorzucić jakąś metodę (PATCH), przesyłać "komendy" np. w postaci mapy [pole, nowa wartość], albo zrezygnować z REST i iść w kierunku dajmy na to GraphQL.

Oczywiście możesz też zrobić po RESTowemu i GET person, zmienić co ma zostać zmienione i PUT obiekt. Niby trochę nadmiarowe, ale łatwiej rozstrzygać konflikty. Co się stanie gdy 2 klientów w tym samym czasie wyśle update tego samego pola na nową (ale różną) wartość? W przypadku PUT masz przynajmniej możliwość zauważenia, że wersja się zmieniła i odesłać http 409.

0
ZrobieDobrze napisał(a):

@Java91:

tego DTO z oczywistych względów nie pchasz do bazy bo jest DTO, ale odszukujesz właściwą encję biznesową / bazodanową, i do niej przenosisz wybrane pola (bo wiesz, które to DTO).
Przy okazji, skoro jest ten "drugi" odczyt encji, można zrealizować "optimistic locking"

Albo jeszcze inaczej. Może zbyt łatwe przypadki są właśnie przez to trudne.

Powiedzmy, ze w DTO przylatuje "szkolny "przelew" miedzy dwoma kontami
konto zródłlowe
konto docelowe
kwota
opis

Nie powtarzasz nazw obu kont, ani ogromu danych (pewnie wiele z nich poufnych - podobnie jak @piotrpo słusznie zauważył problemy securitowe z surowym id) nt obu kont.
Implementacja tego endpoiunta ODSZUKUJE dwie encje itd ...

jaśniej, czym się różni DTO od encji ? Nie ma prostego debilnego przemapowania DTO->jedna encja (w szczególnym przypadku może tak, ale w ogłnym nie)

Jeszcze inaczej,
DTO to jakby argument do jednej z procedur w programowaniu proceduralnym. Byłoby głęboko niesłuszne myśleć, że wywołanie takiej f, (spomiędzy wielu innych) z argumentem totalnie ustawi stan modułu. No nie - jakos tam wpłynie na stan, ale przez szczegółowe atomowe dane.

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