My question is related to Is there a way to prevent null values from being persisted while allowing others through? and Is it necessary to set all the fields of the entity classes when using JPA to persist?, but goes in the opposite direction.
Instead of preventing null values from being persisted, I would like to be sure that null values are consistently used in the generated INSERT INTO statement of a persist operation so that I can detect NOT NULL constraint violations in my application code.
The reason is because my team has a convention on the underlying database (Postgres) that demands that every NOT NULL column also uses a DEFAULT value, which is needed for an automatic migration script we're using.
Due to the problems described in the first linked thread, I want to assure that my JPA (EclipseLink) cache does not get out of sync with the DB due to default values automatically being used upon an INSERT INTO. This could happen if the INSERT INTO completely omits a column - in that case the defined DEFAULT value would be used by the DB to fill the row.
I've observed that EclipseLink always seems to use all the mapped columns in the INSERT INTO statement, explicitly setting null values. This triggers the constraint violation as desired.
But is this guaranteed to happen or could the JPA provider decide to completely omit a column in the INSERT INTO statement that is mapped to a Java field containing a null value (leaving insertable = false annotations aside)?
