awesome session as usually, could you please plan a session about migration using flyway in the future. this is somethoing we encounter usually in projects but it's not wel teached. Thanks Laur.
Hello, Laur. So far in these series you've used the auto generation of the schema, provided by Hibernate. But how to correctly map the table to the class when we do not use the auto-generation option, when there is an existing table already in the db? Should all the table details from DB be mentionated in the entity class? For example, the unique constraints of the table, the sequences names, which columns allow null values
Hi Laur! I have a question regarding to mappedBy. So, from my understanding, mappedBy can be used only in bidirectional relationship to indicate who is the owner of the relationship, aka the side which has the foreign key and who is responsible to manage(set) the foreign key. Also, mappedBy indicates the mapping (table respresentation) that database should use to represent the relationship between two entities. If mappedBy is not used, Spring will understand that you have two individual unidirectional relationship, and it will create two independent ways of reperesenting the relation. Thank you so much for such a great quality content!
Hi. There are a few mistakes here: 1. Spring has nothing to do with mappedBy. I'm not sure why you mention it at all. Maybe you wanted to say Hibernate 2. mappedBy is on the opposite side of the ownership 3. mappedBy doesn't have anything to do with the table/tables. It has to do with the relationship of the objects. It points to the attribute of the other object in the relationship. The rest you said is correct. I hope this helps.
@@laurspilcathank you. Then how should I explain that if I am not using mappedBy there will be mapped or created two ways of representing the relationship. Not sure if I am clear enough
@@adrianstefan1814 Hey, I believe I somehow understood your confusion. First, when the mappedBy attribute is not specified in a bi-directional relationship, the relationship remains bi-directional and not become two-unidirectional relationship. Secondly, If you don't specify the mappedBy attribute, the inverse side will not be aware of the fact that it is a non-owning side of the relationship. It will consider itself as an owning side. You can test this out as well. If you run the application, without specifying the mappedBy attribute, you will notice that JPA will force you to specify a join column(in case if @OneToOne is being used) or join table(in case if @OneToMany is being used) on the inverse side. Why ? because that entity is not aware of the fact that it is on the inverse side of the bi-directional relationship.
hi sir, i am new to hibernate and most of time when i was trying to do things with onetomany or manytomany mapping i got recursive data, and i cant find a good reason for that, please can you just me some advice to handle such thing, i use jsonIgnore to handle it but if feels wrong to me as i never seen you using this in your videos.
Hello. Sure. Please follow the lessons. You'll learn that using bi-directional relationship can cause recurrent calls. I also do explain that you have to be very careful with implementing toString and serialization with Jackson in such cases.
do we need to persist post everytime after first persist? Since it already exists in database so won't every further comment add unnecesary query for insert of post too?.
Hello, not sure if I unserstand the question. But if you mean do we need to persist the related instances individually, the answer is yes. Either that, or use a cascade persist. Hope this helps.
@@laurspilca But what if related instance already in database like I add new content to previous post, when I call find method, won't Post instance already be inside context? so why call persist again for post?
I have a weird question when using ORM especially when maintaining relationships at the entity level. Say in your example we have a Post reference in Comment class. When we follow the DTO pattern for getting data from users We will usually get the post_id in comment DTO. So before persisting the comment entity, we need to get the Post from the post_id because the comment entity doesn't work with the post_id field rather it has a Post object. Doesn't it force me to add an additional query to DB before persisting? I saw in many codebases developers don't maintain relationships at the entity level rather they just add foreign key relationships at the database level. What's your comment about that?
Hello. Making a query is not necessary in your case. As long as you have the ID it should be only a matter of creating an instance new Post(ID). Unless you need the Post data to work with, then there's no reason for making a query.
you got me confused on this one with the owner of the relationship. Is Comment the owner because it holds the FK. Or is Post the owner, because comments belong to the post.
Assume this case in oneToMany in uni directional. Content has Post post annotated with @ManyToOne 1st we add Post and content, here we gotta persist both since there is no post in database and cascade is not set up. we run the app, data get inserted Now my query 2nd - We find the post with id 1, We add one more content and setPost as the post we found above. Do we need to persist post again in this case to? Since post is already available in context. Also, if we do need to persist post again, does it fire insert query in end? (cuz post already exist in database)?
You don't have to persist post again, you can only persist second comment that you're adding to the original post. However, you'll need to persist post and comments in each run if and only if you set "hibernate.hbm2ddl.auto" to "create". Note: using hibernate by setting "hibernate.hbm2ddl.auto" to "create" is illegal in production code.
Thanks
Very awesome content I never seen this type depth content on youtube
Great to hear it helps
awesome session as usually, could you please plan a session about migration using flyway in the future. this is somethoing we encounter usually in projects but it's not wel teached. Thanks Laur.
Yes. Makes sense. Thanks :)
Hello, Laur. So far in these series you've used the auto generation of the schema, provided by Hibernate. But how to correctly map the table to the class when we do not use the auto-generation option, when there is an existing table already in the db? Should all the table details from DB be mentionated in the entity class? For example, the unique constraints of the table, the sequences names, which columns allow null values
Thanks for the question. I'll try to clarify this in the next video.
hello... will you discuss about data validation with hibernate jpa in a future tutorial in this playlist?
Yes
Hi Laur! I have a question regarding to mappedBy. So, from my understanding, mappedBy can be used only in bidirectional relationship to indicate who is the owner of the relationship, aka the side which has the foreign key and who is responsible to manage(set) the foreign key. Also, mappedBy indicates the mapping (table respresentation) that database should use to represent the relationship between two entities. If mappedBy is not used, Spring will understand that you have two individual unidirectional relationship, and it will create two independent ways of reperesenting the relation. Thank you so much for such a great quality content!
Hi. There are a few mistakes here:
1. Spring has nothing to do with mappedBy. I'm not sure why you mention it at all. Maybe you wanted to say Hibernate
2. mappedBy is on the opposite side of the ownership
3. mappedBy doesn't have anything to do with the table/tables. It has to do with the relationship of the objects. It points to the attribute of the other object in the relationship.
The rest you said is correct. I hope this helps.
@@laurspilcathank you. Then how should I explain that if I am not using mappedBy there will be mapped or created two ways of representing the relationship. Not sure if I am clear enough
@@adrianstefan1814 Hei. I'm not sure I understand this last comment. Could you rephrase it please?
@@adrianstefan1814 Hey, I believe I somehow understood your confusion.
First, when the mappedBy attribute is not specified in a bi-directional relationship, the relationship remains bi-directional and not become two-unidirectional relationship.
Secondly, If you don't specify the mappedBy attribute, the inverse side will not be aware of the fact that it is a non-owning side of the relationship. It will consider itself as an owning side.
You can test this out as well. If you run the application, without specifying the mappedBy attribute, you will notice that JPA will force you to specify a join column(in case if @OneToOne is being used) or join table(in case if @OneToMany is being used) on the inverse side. Why ? because that entity is not aware of the fact that it is on the inverse side of the bi-directional relationship.
Do you show how to fetch the collections of a OneToMany with pagination to avoid memory issues?
thanks
Hey. You can do that by writing a JPQL query. The entity manager offers pagination capabilities.
@@laurspilca thank you I just got to that part. You are a great teacher 👏👏
Hello sir
But if i want to track the list of comments for each post then the ownership would be in the post entity right ?
hi sir, i am new to hibernate and most of time when i was trying to do things with onetomany or manytomany mapping i got recursive data, and i cant find a good reason for that, please can you just me some advice to handle such thing, i use jsonIgnore to handle it but if feels wrong to me as i never seen you using this in your videos.
Hello. Sure. Please follow the lessons. You'll learn that using bi-directional relationship can cause recurrent calls. I also do explain that you have to be very careful with implementing toString and serialization with Jackson in such cases.
do we need to persist post everytime after first persist? Since it already exists in database so won't every further comment add unnecesary query for insert of post too?.
Hello, not sure if I unserstand the question. But if you mean do we need to persist the related instances individually, the answer is yes. Either that, or use a cascade persist. Hope this helps.
@@laurspilca But what if related instance already in database like I add new content to previous post, when I call find method, won't Post instance already be inside context? so why call persist again for post?
I have a weird question when using ORM especially when maintaining relationships at the entity level. Say in your example we have a Post reference in Comment class. When we follow the DTO pattern for getting data from users We will usually get the post_id in comment DTO. So before persisting the comment entity, we need to get the Post from the post_id because the comment entity doesn't work with the post_id field rather it has a Post object. Doesn't it force me to add an additional query to DB before persisting?
I saw in many codebases developers don't maintain relationships at the entity level rather they just add foreign key relationships at the database level.
What's your comment about that?
Hello. Making a query is not necessary in your case. As long as you have the ID it should be only a matter of creating an instance new Post(ID). Unless you need the Post data to work with, then there's no reason for making a query.
@@laurspilca Thanks for replying. It's my bad I didn't get this simple technique
you got me confused on this one with the owner of the relationship.
Is Comment the owner because it holds the FK. Or is Post the owner, because comments belong to the post.
The owner is the one where the FK is.
Assume this case in oneToMany in uni directional.
Content has Post post annotated with @ManyToOne
1st we add Post and content, here we gotta persist both since there is no post in database and cascade is not set up.
we run the app, data get inserted
Now my query
2nd - We find the post with id 1, We add one more content and setPost as the post we found above. Do we need to persist post again in this case to? Since post is already available in context.
Also, if we do need to persist post again, does it fire insert query in end? (cuz post already exist in database)?
You don't have to persist post again, you can only persist second comment that you're adding to the original post.
However, you'll need to persist post and comments in each run if and only if you set "hibernate.hbm2ddl.auto" to "create".
Note: using hibernate by setting "hibernate.hbm2ddl.auto" to "create" is illegal in production code.
@@ap0xF ohh, thanx for clearing