You're welcome. This video is an episode of my High-Performance Java Persistence video course. If you liked the video, you are going to love the 11-hour video course vladmihalcea.com/courses/high-performance-java-persistence/
I'm glad you liked it. In fact, you are going to love the video course even more. As for your question, the entity that maps the FK column is the one that should own the relation because FK column values are supposed to be managed via their associated table record.
Is the N+1 queries problem realistically problematic in One-to-One relationship. If my understanding is correct the N in this context will be also 1 hence overall queries will be 2 which is not that bad. It's better to be optimized of course but I would like to validate my understanding with that question.
The issue is problematic because if you load N parent entities with a single query, you will get extra N secondary queries that fetch the children. So, if N is 1000, you will get an extra 1000 queries that are executed one after the other in a blocking manner, which is bad.
This video is an episode of the 11-hour video course, High-Performance Java Persistence. So, if you enjoyed this video episode, you are going to love this video course: vladmihalcea.com/courses/high-performance-java-persistence/
That's a very good question that I frequently get during my training. The @OneToOne relationship basically maps the one-to-one table relationship that was designed 40 years ago and which serves plenty of use cases, like the following ones: - if you have a JSON column that's large, you might not want to fit it on the same page as the original record as that could create page splits, increase the volume of data that gets synced to the disk when the pages get dirty - if you have columns that have different change frequencies, you can split them by write access patterns so that you could have the columns that frequently change in a separate table whose pages get synced often, but they leave the other table pages to reside in the Buffer Pool - to implement the JOINED table inheritance strategy - to split a large table into multiple ones to increase write scalability as UPDATEs and DELETEs take locks at record level in relational databases, and once you change a single column, the entire record gets locked until you commit or roll back. But by splitting the original table into several tables, you can increase the write throughput. - to reduce the optimistic locking conflicts as you have multiple version columns in multiple tables. If you only have a single table, then any column change will cause the other concurrent transactions that also want to change the same record to abort after the first transaction has bumped the version up.
@@aleemkhowaja2274 The solution for that can be done with a Maven or Gradle plugin that it's independent of Spring. So, it works I the same way with Spring as it does with Java EE.
@@aleemkhowaja2274 You're welcome. If you liked this video, there's a 40% discount on the video course: vladmihalcea.teachable.com/p/high-performance-java-persistence-mach-3-online/?coupon_code=BLACKFRIDAY22 But hurry up! It expires in 2 days.
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
Today I have heard about you from my colleague, and I fell in love with your articles and now I am very glad to see you here. Thanks in advance))
Thanks and stay tuned for more
Best explanation I've ever seen. Thank You for explaining this. Your video deserves a million views
You're welcome. This video is an episode of my High-Performance Java Persistence video course.
If you liked the video, you are going to love the 11-hour video course
vladmihalcea.com/courses/high-performance-java-persistence/
Awesome content as always, keep up the good work!
Thanks, Piotr. Stay tuned for more!
Hello @Vlad, this video is perfect! It's a complex topic but your explanation is so good. Thanks a lot.
I'm glad you liked it and stay tuned for more
Excelent video, it was so helpful. Thanks!
You're welcome
Thanks for the great video, as always. Could you please share what visualization tool you are using at 0:45?
The class diagrams were generated with IntelliJ IDEA.
The DB table diagrams with MySQL Browser.
The rest of the diagrams were generated with yEd.
Great video! Now, I'm thinking about whole course :) please, tell me why children entity should be owning side of relation?
I'm glad you liked it. In fact, you are going to love the video course even more.
As for your question, the entity that maps the FK column is the one that should own the relation because FK column values are supposed to be managed via their associated table record.
Is the N+1 queries problem realistically problematic in One-to-One relationship. If my understanding is correct the N in this context will be also 1 hence overall queries will be 2 which is not that bad. It's better to be optimized of course but I would like to validate my understanding with that question.
The issue is problematic because if you load N parent entities with a single query, you will get extra N secondary queries that fetch the children. So, if N is 1000, you will get an extra 1000 queries that are executed one after the other in a blocking manner, which is bad.
Perfect. A video series would definitely be a great add-on for all the hibernate blogs you've written
This video is an episode of the 11-hour video course, High-Performance Java Persistence.
So, if you enjoyed this video episode, you are going to love this video course:
vladmihalcea.com/courses/high-performance-java-persistence/
why do i need to have a one to one relationship? I mean i can wrap the details or include it in the post table
That's a very good question that I frequently get during my training. The @OneToOne relationship basically maps the one-to-one table relationship that was designed 40 years ago and which serves plenty of use cases, like the following ones:
- if you have a JSON column that's large, you might not want to fit it on the same page as the original record as that could create page splits, increase the volume of data that gets synced to the disk when the pages get dirty
- if you have columns that have different change frequencies, you can split them by write access patterns so that you could have the columns that frequently change in a separate table whose pages get synced often, but they leave the other table pages to reside in the Buffer Pool
- to implement the JOINED table inheritance strategy
- to split a large table into multiple ones to increase write scalability as UPDATEs and DELETEs take locks at record level in relational databases, and once you change a single column, the entire record gets locked until you commit or roll back. But by splitting the original table into several tables, you can increase the write throughput.
- to reduce the optimistic locking conflicts as you have multiple version columns in multiple tables. If you only have a single table, then any column change will cause the other concurrent transactions that also want to change the same record to abort after the first transaction has bumped the version up.
How can we achieve this feature in spring data jpa?
Which feature are you talking about?
@@vladmihalcea I mean one to one relationship without n+1 problem which you described in video
@@aleemkhowaja2274 The solution for that can be done with a Maven or Gradle plugin that it's independent of Spring. So, it works I the same way with Spring as it does with Java EE.
@@vladmihalcea ahh ok yaah makes sense to me thanks bro btw great explanation in video and thank you so much for response cheers 🥂 🙂
@@aleemkhowaja2274 You're welcome. If you liked this video, there's a 40% discount on the video course:
vladmihalcea.teachable.com/p/high-performance-java-persistence-mach-3-online/?coupon_code=BLACKFRIDAY22
But hurry up! It expires in 2 days.
Why not make a Post as a relation owner?
Why would I do that?
Video sound is low.
Btw good explanation.
On my latest videos, I increased the volume.