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

Great video

I love your series, It would be interesting if this series will also contains topics such as liquibase, indexing, performance testing, best practices when it comes with large databases, optimistic and pessimistic locking, versioning, testing with JPA and Hibernate

@laurspilca

9 ай бұрын

Hi. Thanks. I will keep out what is not JPA specific. I want this to be a playlist clean only on JPA/Hibernate. But yes, I'll also make videos on all the subjects you mention :)

best jpa playlist so far. thanks

Thank you so much it took me almost two weeks to search for the right content. Eventually i find yours and got the concept. I love your style of teaching. Thank you so much again

@laurspilca

5 ай бұрын

Happy to hear! Enjoy!

Thank you, Laurentiu for such a detailed and nice explanation of Hibernate features . Could you make please series about migrations, that you mentioned and also how to work with No SQL databases in Spring?

Hi Laur, thank you very much for the content! In this topic for many-to-many relationship you said that ORM should not cover join tables but if there is a case where in the join tables we want additional columns to have additional data for specific realtion. For example we have a player and a server tables and we want additional colums for score of the player in the respective server. How do we design it in the database and in the ORM?

@laurspilca

3 ай бұрын

Hi. In the case the join table has other columns it is no longer a join table. It is an entity.

great tutorial!

You can put a comment above that hibernate code, // not to be used in production

@laurspilca

5 ай бұрын

Good idea!

Do you plan to make a tutorial on Flyway or Liquidbase? Apologies if you have already done that.

@laurspilca

3 ай бұрын

Hello. Yes. I plan to do something about this in the near future :)

For people wondering what the answer to Flavor's questions is. I'm assuming it's the most usual cause for "failed to lazily fecth". Imagine you have two entites which have a relationship User and Roles. User has many Roles. The fetch is set to lazy. Do you see how laur opens a transaction does something inside and commits it? So imagine in that transaction we just fetch one user. Nothing more, nothing less. That user ofc has roles but since the fetch is set to lazy we won't get the roles in the context. Then after we commit the transaction we try to access the roles. And since that is not in a transaction and not in the context hibernate will throw that error. Solution is either opening a new transaction or making the fetch eager. (And maybe doing unproxy but I don't know it well enough to suggest it)

@laurspilca

9 ай бұрын

Yeap. This is totally true. Once you closed the transaction you can't get the lazily fetched data.

thanks again for the great content! tbh though, i don't understand the purpose of using jointables, is there a short and concise answer to this, or maybe are there resources that could provide relevant knowledge or examples?

Another Question in this example for specially for Bidirectional but not necessary we need to link the entities instances but remember to connect them, it could be something that people will miss is there a way we can avoid this issue, The same applies for the other types of like @OneToOne and @OneToMany, I might forget to link the entities like users to groups, post to comments, user to address etc. etc... Do you know if there is a pattern to avoid this, what would be good practice? ex. Group g1 = new Group() Group g2 = new Group() User u1 = new User() User u2 = new User() g1.setUsers(List.of(u1, u2)) g2.setUsers(List.of(u1)) u1.setGroup(List.of(g1,g2)) u2.setGroup(List.of(g1));

@laurspilca

3 ай бұрын

Well, we do need bi-directional relationship. You cannot avoid this. I don't know a way to enforce the link. So, the best is to test your implementations properly. Usually you'll observe inconsistencies in the data if you miss something :)

Those who are getting sql error when SQL Error: 1064, SQLState: 42000 while trying to insert data in groups table when running the application. I am at 27:40 sec mark. I found that it is due to the fact that "groups" is a reserved word in mysql database. Hence getting the error. To get around this error please add backticks (`) character around the @Table annotation in Group entity. @Table(name = "`groups`"). New query generated will look like insert into `groups` (name) values (?) I am wondering why its not happening in the video. Can someone explain ?

@nipunkataria4588

9 ай бұрын

I am using mySQL version 8.0.33-0ubuntu0.22.04.2 for Linux on x86_64 ((Ubuntu))

@laurspilca

9 ай бұрын

Hi. It can be related to the MySQL version you use.

@grigorypiskunov418

6 ай бұрын

you can rename table to ugroups e.g. and update class. It will works for you.

Thanks a lot, Laur, question in the beginning of the video, what do you mean is better have multiple OneToMany that a ManyToMany I understand about performance and simplicity would be easier, but I don't get how you can replace it with multiple OneToMany, can you show an example to be more clear? Thanks

@laurspilca

3 ай бұрын

There is no right answer to that since it really depends on the case. Both are good if used properly.

will there be lesson about HQL queries? i.e JOIN FETCH?

@laurspilca

10 ай бұрын

Yep. But I'll actually refer to them as JPQLs since we discuss broadly about JPA.

What if users_groups table has its own values. For example if we want to have date when user joined the group?

@laurspilca

10 ай бұрын

Hi. Thanks for the question. If that table has its own values it means it's no longer a join table but a real entity with attributes.

@fipabrate

10 ай бұрын

@@laurspilca and then we use one to many to that entity

What if we need to add custom columns in the join table ?

@laurspilca

3 ай бұрын

Hello. Good question. Then it's not a join table anymore -> it becomes an entity.

if the join table has an attribute such as date, can it be considered as an entity or it remains to be a join table?

@laurspilca

9 ай бұрын

Yes. In that case it's not a simple join table anymore. But that doesn't mean it's also a good design. One who design the data model should ask themselves, what does that entity represent? Is that a good way to model the data? This depends on the case of course.

Hey Laur! Quick question. Since you said having a join table as an entity is an anti-pattern and shouldn't be done. And also never modeling the relatioship as ManyToOne and OneToMany instead of ManyToMany. I'm currently making a project which has a 3-way join table. User, Company, Role. Basically trying to achieve the same thing as discord. Having different roles for each company for each user. I have an entity for that join table which has unidirectional @ManyToOne relationships with all 3 other entities. What would suggest I change or do you think what I've done is fine?

@laurspilca

9 ай бұрын

Hi. I don't understand. In your case you really have three entities and not a many-to-many. What I was saying it's an antipattern is to force a join table being an entity. That doesn't mean you won't have situations where you really have an entity between two other entities. I hope this helps.

@BravePro

9 ай бұрын

@@laurspilca Fair enough haha. Didn't think of it that way. Thanks!

Could you make E-commerce project, please?

@laurspilca

10 ай бұрын

As an example you mean? Yes. Let's take this however outside the series since it would cover multiple technologies.

@mostafasaleh2806

10 ай бұрын

@@laurspilca Thank you Sir.