I think we have a fairly standard database that looks like a parts BOMB.  Someone had the neato idea to use cascading delete in the project.  Hibernate’s cascading delete will follow any required foreign key and delete the children it finds there in a cyclical manner.  Good idea, huh?

No.  This means parent entity Parent with a primary key of ParentPrimaryKey MUST cascade it’s primary key to all children.  So, entity Child has a primary key of ChildPrimaryKey PLUS ParentPrimaryKey.  This continues all the way down your entity tree.  This example assumes simple row id’s for primary key.  If there was some other overriding attribute which makes every primary key a composite, like SystemThatThisEntityLivesOn, then every level has one of those plus all the parent’s.

Then we realize, we can’t actually delete some of the lower level entities because they are a lot of work to create.  So, we configure Hibernate to stop at those entities.

Now if we step back and look at the entity diagram for our database it is not uncommon for an entity at a lower level to have close to 20 component parts of a primary key that have cascaded down.

But, we only delete via cascade a very small subset of the entity tree.

Now, throw into the mix some developers who don’t understand the above features of a relational database or Hibernate in general and we now can’t use the LowLevelEntityId composite object that Hibernate generates as that is ‘unclean’.  We are to flatten all of these id’s wherever used.