Najlepszy sposób na obsługę wyjątków w CRUD

0

Czesc, jaki najlepszy sposób polecacie na obslugę sytuacji w której wołam do bazy , z poziomu formularza, o usuniecie encji, która nie istnieje, wtedy "z bazy", idzie wyjatek, czy tutaj jedyna opcja jest lapanie tego wyjatku, czy mozna to zrobic schludniej?? K

Jak dobrze zakładam - validacja na poziomie formularza odpada, istnieja jakies zmodyfikowane wersje zapytan w takich przypadkach?

Widzialem rozwiazanie z retrieve i sprawdzeniem null'a jednak to juz sa 2 zapytania do jednego celu, wiec chyba tez srednio optymalnie..

U siebie uzywam

entityManagera.remove();

i wtedy idzie
InvalidDataAccessApiUsageException

1

A nie możesz po prostu opakować w try-catch linijki kodu, w której zatwierdzasz transakcję?

0

a nie możesz sobie najpierw puścić selecta isExist. wtedy nie masz wyjątku tylko if(isExist w jakimś miejscu i tyle. łapac taki wyjątek gdzieś wysoko w appce to średnio wygląda

łap wyjątek i wyżej rzucaj własny.
dzięki @maryiusz

7
karolinaa napisał(a):

a nie możesz sobie najpierw puścić selecta isExist. wtedy nie masz wyjątku tylko if(isExist w jakimś miejscu i tyle. łapac taki wyjątek gdzieś wysoko w appce to średnio wygląda

isExist ? dobra nazwa - już po polsku można było napisać...

Chcesz, zrobić dodatkowo jeden request do bazy zobaczyć czy wartość istnieje ? czyli dla 1000zapytań zrobi sie 2000zapytań ?
Dodatkowo, wiesz że zanim przyjdzie odpowiedź z bazy, ktoś możee wywalić te encje z bazy ? musiała byś robić optimistic locking, serio ?

0

rzucanie wyjątków na serwerze i ExceptionMappery w Jerseyu.

0
maryiusz napisał(a):
karolinaa napisał(a):

a nie możesz sobie najpierw puścić selecta isExist. wtedy nie masz wyjątku tylko if(isExist w jakimś miejscu i tyle. łapac taki wyjątek gdzieś wysoko w appce to średnio wygląda

isExist ? dobra nazwa - już po polsku można było napisać...

Chcesz, zrobić dodatkowo jeden request do bazy zobaczyć czy wartość istnieje ? czyli dla 1000zapytań zrobi sie 2000zapytań ?
Dodatkowo, wiesz że zanim przyjdzie odpowiedź z bazy, ktoś możee wywalić te encje z bazy ? musiała byś robić optimistic locking, serio ?

no dobra racja aa czy w przypadku załóżmy unique constrainta na AccountModel.login i jest metoda @Transactional save() i zapisujemy użytkownika do bazy ma sens w
tej metodzie sprawdzać if(userDao.existByLogin(userLogin)) i jeżeli istnieje to rzucać własny wyjątek czy lepiej tego nie sprawdzać tylko łapać wyjątek naruszenie constrainta
który rzuci hibernate i po złapaniu wyżej rzucać już odpowiedni własny wyjątek.

0

unique constrainta na AccountModel.login

??? w sensie synchronized ? bUUUJ się boga

0

@karolinaa
Jeśli robisz: @Transactional oraz save()/persist() to spodziewaj się możliwości duplicate entry.

0

@Shalom @Krwawy Szczur @maryiusz2 czyli nie sprawdzac tylko lapac wyjatek

1

I tak musisz potencjalnie łapać ten wyjątek i obsługiwać taką sytuacje. Dodając "sprawdzenie" wcześniej niczego nie zyskujesz.

0
Shalom napisał(a):

I tak musisz potencjalnie łapać ten wyjątek i obsługiwać taką sytuacje. Dodając "sprawdzenie" wcześniej niczego nie zyskujesz.

jak się używa repozytoriów springa np. do updatu i tam jest save() to czasem może warto sprawdzić czy istnieje, bo jak przyjdzie null w id to wpisze nam nowy rekord ;)

0

Dzięki to dla mnie bardzo cenna wiedza.

0

jak się używa repozytoriów springa np. do updatu i tam jest save() to czasem może warto sprawdzić czy istnieje, bo jak przyjdzie null w id to wpisze nam nowy rekord ;)

Null nie przychodzi. Jeśli po zapisie masz nulla, to znaczy, że... nic nie przyszło, bo sesja nie została spłukana ;) Możesz to wymusić.

0
Shalom napisał(a):

I tak musisz potencjalnie łapać ten wyjątek i obsługiwać taką sytuacje. Dodając "sprawdzenie" wcześniej niczego nie zyskujesz.

@Shalom mam jeszcze jedno pytanie. Czy analogicznie to się tyczy sytuacji typu:

Wpada mi do serwisu DTO GroupMemberDTO z nieistniejącym groupId.
nie ma tam wielkiej logiki tylko mapowanie na encje i zapis do bazy.

nie robię walidacji przed save'em sprawdzając czy groupDao.existById tylko od razu
wołam groupMemberDao.save w try catcu i jeżeli się nie uda łapię wyjątek hibernetowy/jpa i wyżej rzucam sobie swoj?

informacyjnie w GroupMemberEncjiModelu mam dobrze prawidłowo zrobione mapowanie manyToOne czyli ta encja ma pole
private Group group;.

0

@karolinaa jeśli masz to poprawnie skonfigurowane (tzn ze faktycznie constraint to chwyci) to możesz tak zrobić. Bo przecież chyba widzisz że alternatywnie możesz sprawdzić czy grupa istnieje a potem w międzyczasie zanim dodasz tego usera ktoś grupę może i tak usunąć ;] Siłą rzeczy i tak musisz tą sytuacje sprawdzić.

0

@Shalom ok dzięki.
Tak widzę bezsensowność takiego sprawdzania, gdy do bazy pisze wielu i jednocześnie. Po prostu od zawsze w sofcie komercyjnym spotykam się z tymi sprawdzeniami
if(existByName) itd

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