Hi,
we have a requirement to partition some of the existing tables by create timestamp. The Primary key constraint on the PK column has to be dropped now since it is not part of the the partitioning column list (column will be retained with auto increment in MYSQL, but without PK constraint , will add Unique Index on the column instead) .

Questions we have from hibernate perspective are,

1) we have an Entity mapped to this table already, can the <ID> mapping to the above column still be retained after PK constraint has been removed, but with unique index created on it or PK constraint for this column in the table is required?

2) similarly for mapping one to many relationships from parent -> child tables, is having a FK constraint created on the join column is absolutely required for hibernate to load the data or it can work without that too with the join column not having any FK constraint ?

I understand above even if they could work there could be data issues arising from the absence of the constraints and not a good practice, but we would like to know if it is possible in the first place as these tables are more of audit data so not very critical from data integrity perspective.

regards,
aravias

Hi,

Hibernate is very lenient in this regard:

1. You don't even need to use a PK for the entity identifier. Any unique column can work just fine. The only requirement is for the column to be unique, and that's it.
2. For any association, Hibernate does not require a FK to actually be present on the database side. It can take any column that has a peer on the other table. SO no worries here as well.

But just like you said, having a PK for the id and a FK for the association join column is so much better for data integrity.

Vlad