Yes. We can preload them with a standard set of questions as well.
Then I guess we have to keep the link of the doc in the mentee table. Just to clarify, a user would have to create multiple docs to apply to multiple mentors right?
ERD design call 2 - finalizing ERD
When: 2020-07-30T12:30:00Z â 2020-07-30T14:00:00Z
Where:
Attendees: @jaye @Gravewalker @Gimhan_minion @anjisvj @piumal1999 @YohanAvishke
Diagram:
Editable file:
GitHub Project board:
Good job team!
Canât mentee join a program before selecting a mentor?
Hi @shyamal, no users have to select a mentor inorder to apply as a mentee
Added changes due to discussions in the thread.
1 Like
Thanks @YohanAvishke,
Could you please come up with a small comparison on âCreating the DB tables manuallyâ vs âLetting Hibernate to generate the tablesâ?
1 Like
Hi @YohanAvishke,
Where are we up to now on this task?
Hi, I did some research on finding the best approach for database initialization and data management.
SpringBoot recommends any of the following ways to initialize the database,
- JPA, Hibernate, basic SQL scripts
There is no logical difference between these approaches. And the approach that one should use completely depend on the technologies of the project itself.
But however, since the main reason we are trying to use basic SQL scripts is the issue with Cascading, I did some further digging to check if itâs recommended to use the Cascading on the script itself.
And the approach is not recommended because
Hibernate doesnât know which records the cascading operation on the database removes. It canât remove any entity that maps one of the removed records from the 1st or 2nd level cache. Due to this, you are at a high risk that your caches contain outdated information (records that no longer exist).
In other words, the SpringBoot database cache can get invalidated and we will be forced not to use the EntityManager .
So the best approach would be as follows,
- Let the database initialization through JPA Entities without adding Cascading to any of the
to manyrelationships. - When a bulk removal is needed(Eg: Removing children of a parent) write native SQL scripts in the Repository to provide the functionality.
This approach will solve the above mentioned caching problem and the following 2 problems,
- When using JPA delete with Cascade for a
to manyrelationships, a huge number of SQL scripts will be executed. - When using JPA delete with Cascade for a
many to manyrelationships, a chain removal might occur and might end up removing all the data.
References:
i. https://docs.spring.io/spring-boot/docs/2.3.2.RELEASE/reference/html/howto.html#howto-database-initialization
ii. https://thorben-janssen.com/avoid-cascadetype-delete-many-assocations/
WDYT about the above approach?
2 Likes
Thank you so much for the very informative comparison @YohanAvishke!
Seems letting Hibernate to generate tables might be a good practice.
1 Like
Changes requested in the thread
https://drive.google.com/file/d/1L7OXu9KQkxEuWSp-ke7vqSQlS9xaFpPY/view
Reasoning for the changes: