Czy to @NotNull ma to samo znaczenie co @Column (nullable = false) ?
0
1
@NotNull jest z pakietu javax.validation (choć cholera wie - bo więcej bibliotek go wynalazło, świta mi blado że Spring ma swój).
Zwykle zamiarem jest używanie tego w kodzie (tzn nie w definicjach danych) w połączeniu z mniej czy bardziej magicznymi walidatorami.
@Column jest z pakietu javax.persistence (JPA)
Do tworzenia rozwiązań bazodanowych należy używać @Column z opcjami.
Do @NotNull są liczne (negatywne) dyskusje, wielu uważa że default to not nul a @Nulalble ma znaczenie.
Obie zdaniem środowiska powinny odejść, a jaskółką wiosny jest klasa Optional (nie adnotacja) akurat dyskutowana obok w wątku, sugeruję się zainteresować (choć niekoniecznie od razu temu wątkowi, np YT)
0
Różnica jest taka, czy exception ma ci wyrzucić Hibernate przed wygenerowaniem SQLa, czy też wolisz dostać exceptionem bezpośrednio od bazy:
https://www.baeldung.com/hibernate-notnull-vs-nullable
0
Obczaj sobie jakie query Ci Hibernate wygeneruje. W obydwu przypadkach zostanie dodany constraint 'not null' lecz jeśli wartość będzie nullem to w przypadku @NotNull dostaniesz na twarz constraint exceptionem i do bazy żadne query nie poleci, w przypadku @Column (nullable = false) poleci query do bazy i dostaniesz jakiś jdbc exception
2
Skoq napisał(a):
Obczaj sobie jakie query Ci Hibernate wygeneruje. W obydwu przypadkach zostanie dodany constraint 'not null' lecz jeśli wartość będzie nullem to w przypadku @NotNull dostaniesz na twarz constraint exceptionem i do bazy żadne query nie poleci, w przypadku @Column (nullable = false) poleci query do bazy i dostaniesz jakiś jdbc exception
Poprawię
Takie działanie @NotNull na schemę nie jest standardowe w JPA, jest rozszerzeniem Hibernate. Ja osobiście rozszerzeń, o ile istnieje standard, nie lubię.
https://www.baeldung.com/hibernate-notnull-vs-nullable
Nawiasem mówiąc artykuł objaśnia wszystko
Zachęcam do rozumienia co-jest-skąd, z którym to problemem w kręgu Springa MSZ nie jest dobrze.
3
Odbiegając od tej funkcjonalności w samym JPA -> zastanów się czy przed nullem nie warto zabezpieczyć się na warstwie wyżej niż warstwa encji. No bo zobacz - ten niepoprawny null po drodze przejdzie pełno warstw mogąc spowodować NPE i dopiero na dosyć niskim poziomie chcesz aby biedne JPA to wychwyciło i walnęło wyjątkiem, że null. Oczywiście możesz stwierdzić, że coś takiego broni twoją aplikacje przed nullowymi wartościami z bazy - ale aplikacja nie powinna bronić się przed bazą a jej ufać i ją ochraniać. Dlatego zakazujemy jakichkolwiek modyfikacji z ręki na bazie - wszystkie operacje na bazie idą przez punkt wejścia i logikę aplikacji. Dzięki temu nie tracisz aż tak dużo czasu na warstwę IO (źródło danych), którym jest baza danych i JPA a po prostu takie rzeczy olewasz i masz do tego pełne zaufania - bo wiesz, że baza ma spójny stan a wszelkie nulle itd... są wyciachane już znacznie wcześniej na wyższym poziomie. Zwróć uwagę np. że język taki jak Kotlin już na etapie definicji zmiennej sugeruje Ci użycie typu non nullable abyś unikał NPE -> czyli zobacz jak bardzo defensywne to jest - dlatego uważam, że powinieneś ciachać nulle wcześnie i bezlitośnie.