Orphan removal and Cascade.REMOVE

 Cascade.ALL is used to apply all operations on the children table which are getting applied on parent
Operation includes
- Delete -  If parent is deleted then all children will be deleted.
- Persist - If parent is persisted then all children will be persisted.
- Update/Merge - If parent is updated then all changes in each children will be updated.
- Reload -  If you reload parent from DB, all children will be reloaded.
- Detach -  If parent is detached from the hibernate session all children will also be detached.

⚠️ The Danger Zone CascadeType.ALL is powerful but can be risky: 

- Accidental Deletes: If you delete a Department, you might delete 500 Employees you didn't mean to.      - Performance: If you have a massive list, a simple update to the Parent might trigger checks/updates on every single Child.
- Global Impact: It is usually better for Composition (where the child can't exist without the parent, like an Invoice and InvoiceItems).

⚠️ When to AVOID CascadeType.ALL 

While great for Composition (Invoice -> Items), avoid it in Aggregation (User -> Role):
- Shared Entities: If an Employee can belong to multiple departments (Many-to-Many), CascadeType.REMOVE will delete an employee that other departments still need.
- Large Collections: If a department has 10,000 employees, loading the parent just to add one child is a performance killer. In that case, use @ManyToOne only on the child.


orphanRemoval Vs Cascade.REMOVE

Cascade.Remove detach the child, for example a user have posts so if we are deleting one of the post of that specific user then via Cascade.REMOVE it will not delete the post it will simply run the update command and set the user id against that post to null, the deleted row of post will be persisted in the db but without any user id.

on the contrary orphanRemoval will delete the row.






Comments

Post a Comment

Popular posts from this blog

Kubernetes terms made easy

when we have docker compose and we can define rules to run our containerized applications over there ... so why do we need k8s...? Well we can certainly manage very small containers... but handling large scale applications through this will certainly be a nightmare... Because ... large apps will need to scale automatically.. and docker compose requires manual intervention and scripting .. ahhh who will re invent the wheel... Let's k8s do this... Now when we know the importance of k8s .. we have to learn it's core components and it's architecture level working... k8$ environment have a company named ... control pane .. who is responsible for managing and running kubernetes clusters ....  This company, named control pane.. have a CEO.. named, API Server ...I wasn't talking about the actual CEO of kubernetes 😅... just an analogy... Every one discuss there matters with API server ... and api server talks to everyone ... It's kind of a brain of the company...  Next come...
Read more

Anomalies in Database

Anomaly is a fault which occurs in the poorly designed database , which leads to inconsistent, redundant and inefficient data. There are three kind of anomalies: - Insertion anomaly - Updation anomaly - Deletion anomaly Insertion Anomaly It occurs when we want to insert a particular kind of data, let's say Data#1, but due to the absence of a certain data, let's say Data#2, we were unable to add. Example If we have only one table for saving student and course, named std_course. We won't be able to add the new course until, we have the student information. std_course Table  Student_ID Student_Name Course Instructor Instructor_Contact 101 Ali DBMS Mr. Khan 123456789 102 Ahmed OS Mr. Ahsan 987654321 Suppos...
Read more