Design the Initial ERD of ScholarX

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:00Z2020-07-30T14:00:00Z


Attendees: @jaye @Gravewalker @Gimhan_minion @anjisvj @piumal1999 @YohanAvishke


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.

Updated diagram with newly added mentee - program relationship

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 many relationships.
  • 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,

  1. When using JPA delete with Cascade for a to many relationships, a huge number of SQL scripts will be executed.
  2. When using JPA delete with Cascade for a many to many relationships, a chain removal might occur and might end up removing all the data.


WDYT about the above approach?


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

Reasoning for the changes: