Design the Initial ERD of ScholarX

[akshika47]

Yes. We can preload them with a standard set of questions as well.

[Gravewalker]

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?

[YohanAvishke]

ERD design call 2 - finalizing ERD

When: 2020-07-30T12:30:00Z → 2020-07-30T14:00:00Z

Where:

Meet

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

Diagram:

Editable file:

ScholarX ERD.drawio

GitHub Project board:

Build software better, together

[shyamal]

Good job team!

Can’t mentee join a program before selecting a mentor?

[YohanAvishke]

Hi @shyamal, no users have to select a mentor inorder to apply as a mentee

[YohanAvishke]

Added changes due to discussions in the thread.

[YohanAvishke]

Updated diagram with newly added mentee - program relationship

[jaye]

Thanks @YohanAvishke,

Could you please come up with a small comparison on “Creating the DB tables manually” vs “Letting Hibernate to generate the tables”?

[jaye]

Hi @YohanAvishke,
Where are we up to now on this task?

[YohanAvishke]

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.

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?

[jaye]

Thank you so much for the very informative comparison @YohanAvishke!

Seems letting Hibernate to generate tables might be a good practice.

[YohanAvishke]

Changes requested in the thread

https://drive.google.com/file/d/1L7OXu9KQkxEuWSp-ke7vqSQlS9xaFpPY/view

Reasoning for the changes:

Creating a view for Apply as a Mentor

Later after the mid-week call we decided that using steps is not needed because there are only 2 questions for mentor. So we thought to add 2 text areas for mentor to answer. Therefore during the call @jaye created the below wire-frame to understand about further development. [image] This is the new wireframe According to the above wireframe I changed the mentor application view as below. [image] Please let me know your thoughts