I'm glad you liked it. This video is part of my High-Performance Java Persistence video course, so if you liked this video, you are going to love the video course. vladmihalcea.com/courses/high-performance-java-persistence/
@@vladmihalcea I am convinced that your course is flawless and will provide invaluable experience for students, beginners and experienced staff. Thank you for sharing your expertise. The future lies with smart and kind people. You're part of the future, Vlad.
Thats great to know! but i dont understand why they would differ in the implementation between the list and the set, since to me at least it seems that they act simply as a container
In my opinion, it's much simpler to just keep all three tables as the ones without any *ToMany relations and do all the stuff by hand. Looking at the complexity of the utility methods, as well as mapping verbosity of the entities, it will be easier to do all the activities in the code directly (better to read, better to modify and support). For example, if we need to add a new many-to-many relation, we just persist manually all two parents and then add a new entity representing many-to-many relation. The same is about removal - just remove the desired record(s) from the join table, and then delete the parent ones!
You can map the intermediary table as an entity and get both the convenience of the entity relationship and the flexibility of adding new columns and get the same performance of doing the operations manually.
@@vladmihalcea Thanks for your reply. I don't have the finite opinion on that, but anyways... I'm not sure, that auxiliary table will address complexity issues here... I may be wrong, but it seems simpler to just create two parent entities without any *ToMany relations inside, and the one entity representing join table with one-to-one relation on these parents. In my view, add/remove of both parents and relations between them should be much easier in this regard, as well as understanding of the code. Of course, not everything is cloudless with such an approach. For instance, I'm predicting a lot of troubles with further conversion of the retrieved entities into DTO/JSON to propagate it further as a REST API response: if we had *ToMany parent-child entity, it will be converted into one JSON automatically keeping "children" field as an array of relations. But in case of separate entities, you should do extra activities to compile different entity objects into one DTO/JSON.
@@Exterminator131 You don't need to convert entities to DTOs. You can simply extract Hierarchical DTOs directly from the DB, as I explained in this article vladmihalcea.com/one-to-many-dto-projection-hibernate/ Fetching entities only to discard what you don't need and create a DTO is wasteful. If you think that avoiding the collections is easier for you, then you should not map the associations. In the end, any collection can be replaced with a query.
You can find a detailed explanation of your question in my High-Performance Java Persistence video course. Enjoy watching almost 11 hours of video lessons: vladmihalcea.teachable.com/p/high-performance-java-persistence-mach-3-online
Hi @vladmihalcea , Thank you for the prompt reply. Let's say I am storing roles for a tenant and the associated user. so my join table will have user_id, role_id and tenant_id and some extra colums. My question was, can we apply the same logic as suggested in the video in this case too?
@@Abhishekchandel008 Your join table can have extra columns and extra associations. Check out my High-Performance Java Persistence video course for more details: vladmihalcea.teachable.com/p/high-performance-java-persistence-mach-3-online
@@Abhishekchandel008 There's always a better way. However, that requires analyzing your schema and the business requirements. Luckily, I do offer consulting if your company is interested in improving their codebase.
Great video, Vlad.
Thank you very much.
I'm glad you liked it. This video is part of my High-Performance Java Persistence video course, so if you liked this video, you are going to love the video course.
vladmihalcea.com/courses/high-performance-java-persistence/
@@vladmihalcea I am convinced that your course is flawless and will provide invaluable experience for students, beginners and experienced staff.
Thank you for sharing your expertise.
The future lies with smart and kind people. You're part of the future, Vlad.
Thats great to know! but i dont understand why they would differ in the implementation between the list and the set, since to me at least it seems that they act simply as a container
@@dejvisbeqiraj1090 When in doubt, just check the generated SQL statements. That's how you can tell what performs the best.
In my opinion, it's much simpler to just keep all three tables as the ones without any *ToMany relations and do all the stuff by hand. Looking at the complexity of the utility methods, as well as mapping verbosity of the entities, it will be easier to do all the activities in the code directly (better to read, better to modify and support). For example, if we need to add a new many-to-many relation, we just persist manually all two parents and then add a new entity representing many-to-many relation. The same is about removal - just remove the desired record(s) from the join table, and then delete the parent ones!
You can map the intermediary table as an entity and get both the convenience of the entity relationship and the flexibility of adding new columns and get the same performance of doing the operations manually.
@@vladmihalcea Thanks for your reply. I don't have the finite opinion on that, but anyways... I'm not sure, that auxiliary table will address complexity issues here... I may be wrong, but it seems simpler to just create two parent entities without any *ToMany relations inside, and the one entity representing join table with one-to-one relation on these parents. In my view, add/remove of both parents and relations between them should be much easier in this regard, as well as understanding of the code.
Of course, not everything is cloudless with such an approach. For instance, I'm predicting a lot of troubles with further conversion of the retrieved entities into DTO/JSON to propagate it further as a REST API response: if we had *ToMany parent-child entity, it will be converted into one JSON automatically keeping "children" field as an array of relations. But in case of separate entities, you should do extra activities to compile different entity objects into one DTO/JSON.
@@Exterminator131 You don't need to convert entities to DTOs. You can simply extract Hierarchical DTOs directly from the DB, as I explained in this article
vladmihalcea.com/one-to-many-dto-projection-hibernate/
Fetching entities only to discard what you don't need and create a DTO is wasteful. If you think that avoiding the collections is easier for you, then you should not map the associations. In the end, any collection can be replaced with a query.
Could you please elaborate on the cases where it is better to map the Join Table in a separate JPA Entity?
Thanks in advance
You can find a detailed explanation of your question in my High-Performance Java Persistence video course. Enjoy watching almost 11 hours of video lessons:
vladmihalcea.teachable.com/p/high-performance-java-persistence-mach-3-online
What do you recommend, if there are multiple many to many relationship in the same join table?
I don't see how the same join table could ever be used to store multiple FK sets for different parent sets.
Hi @vladmihalcea , Thank you for the prompt reply. Let's say I am storing roles for a tenant and the associated user. so my join table will have
user_id, role_id and tenant_id and some extra colums. My question was, can we apply the same logic as suggested in the video in this case too?
I am using the same mapping as suggested in the video, for my case as well, just wanted to know if there are better ways than this.
@@Abhishekchandel008 Your join table can have extra columns and extra associations. Check out my High-Performance Java Persistence video course for more details:
vladmihalcea.teachable.com/p/high-performance-java-persistence-mach-3-online
@@Abhishekchandel008 There's always a better way. However, that requires analyzing your schema and the business requirements. Luckily, I do offer consulting if your company is interested in improving their codebase.