JPA/Hibernate Fundamentals 2023 - Lesson 5 - One-to-one relationship

[@laurspilca]

Code on GitHub: github.com/lspil/youtubechannel/tree/master/jpa_2023_c5_e1

[@momedalhouma14]

I liked the way you explained the things in this session. speaking about best practices and pitfalls is awesome. thank you

[@hardcorecode]

@secondaryTable annotation looks awesome.... Can't wait to try it out!

[@patrisrikanth]

Awesome session as always

[@ivanjelikj87]

As always, Laur explains it perfectly!

[@0-100Dev]

Hi Laurentiu , my doubt is not related to this session , I just wanted to know if you are going to discuss about the L1 , L2 cache and Connection Pooling mechanism of hibernate ? Btw I have been following the series till now . Loved all the sessions.

[@laurspilca]

Yes. I think somewhere at the end maybe.

[@AliHassan-ty2me]

Thanks :) for the awesome content !. I have two stupid questions: 1. What does it mean when you say "this field owns the relationship" ? 2. What does the term cascade mean? Sorry for asking such silly questions 😅. I am just not confident about these terms.

[@laurspilca]

Hi. Thanks for the question. 1. The owner of the relationship is basically where the foreign key is in the tables. This doesn't not apply to the many-to-many where the owner is just conceptual (meaning you choose one or the other). 2. Cascading means that when you apply a context operation (PERSIST for example) it automatically gets applies to the objects that instance has relationship with. I hope this helps.

[@AliHassan-ty2me]

@@laurspilca thanks :) It was really helpful.

[@a.m.jyotiprakashsahu5754]

sir, please make a video on Spring security 6 with Keycloak using OpenID.

[@kamilwawer9949]

I have a question regarding uni and bi-directional relations: It sounds convenient to always have bi-directional relations. Then it's always available to use two-way to get other entities, even if we don't need it. Are there any known scenarios or cases which highly recommend using only a unidirectional way?

[@laurspilca]

Hey. Thanks for the question. As we aim to simplify the code, from a maintainability perspective it's better to go with uni-directional. Using a bi-directional relationship offers more flexibility but creates more complex code. So, if you don't need one of the sides, go with a uni-directional.

[@BravePro]

One place where uni-directional would save you tons of time is when you use DTOs. Will just make your life way easier during mapping. Basically as Laur said if you can go without bi-directional relationship you'll save yourself tons of complexity and time.

[@saumilvachheta]

Sir, in the Live section, there are a lot of old videos of Java, Spring Security, Spring JPA. Is it good to watch those videos? Will those be useful to learn for modern Spring Development or the syntax of framework has changed drastically?

[@laurspilca]

I guess all of them can be useful. If you have double about any specific, ask me.

[@rationale-emotions]

At 45:15 wherein you explain about SecondaryTable annotation, I was thinking if vertical partitioning of a table into several logical tables be a use case for using this annotation ?

[@laurspilca]

Yes, you can. Sometimes you need to do that to improve performance for specific cases.

[@boomirajpalraj]

What type of query do you recommend: joins or subqueries? When using a @Query??

[@laurspilca]

Hello. Good question. I think it depends on many factors. I'd chose the most performant approach depending on the case.

[@flaca7342]

Hi Laur, where can i follow you bisides youtube. I love the way you explain. You are so clear. Thanks in advanced and sorry for my english :P

[@laurspilca]

Hello. I'm active only on Twitter (X) and LinkedIn :)

[@flaca7342]

Thank you, @@laurspilca . I search for you in linkedin and cannot find you. I don't have twitter. Have a nice day :)

[@flaca7342]

@@laurspilca I found you :) Dismiss the other message. Thanks again.

[@ziadahmed1634]

Hi laur i have question in one to one if i have same example person owing passport and in passport i make lazy fetch for person it always call person eager what reason for that the inverse works well

[@laurspilca]

Hi. Depends on how you tested that. Rememeber that lazy means it is taken when needed it. So... you will see two SQL queries in the logs. How many queries do you see? This is the only way you can conclude is eager or lazy.

[@unclassicfusion]

Why wasn't it necessary to use mappedBy on the Person side?

[@laurspilca]

Hi. Thanks for the question. You mean in a bi-directional relationship? One side is enough for it to establish the relationship. It simply knows that one is the one marked with mappedBy and the other is the one mappedBy points to.

[@fipabrate]

fetch type that ends with @...ToOne is always Eager, while @...toMany is Lazy by default

[@laurspilca]

That is another way of saying it. But important is why. And the reason is because you don't want collections to be eagerly loaded :)