Steve Ebersole Users can still run native SQL queries to circumvent our @Immutable checks. JPQL and HQL being entity-oriented, I thought that it's better to guard against such use cases that might indicate some application-level bugs.

For soft-deletes, we only provide the means for users to do that, but we don't know if the queries employed by our users that override the default CRUD ones are meant for soft deletes.

I could add a setting to control what action to take when updating an immutable entity:

• log a warning
• throw an exception

Is this ok with you too? We could log a warning by default as, otherwise, some current JPQL queries will fail if users have employed them to update @Immutable entities in the past.