Closed gavinking closed 11 months ago
As possible starting point for discussion, here's an API we recently added to Hibernate:
public interface SchemaManager {
/**
* Export database objects mapped by Hibernate entities.
*
* @param createSchemas if {@code true}, attempt to create schemas,
* otherwise, assume the schemas already exist
*/
void exportMappedObjects(boolean createSchemas);
/**
* Drop database objects mapped by Hibernate entities, undoing the
* {@linkplain #exportMappedObjects(boolean) previous export}.
* <p>
* @param dropSchemas if {@code true}, drop schemas,
* otherwise, leave them be
*/
void dropMappedObjects(boolean dropSchemas);
/**
* Validate that the database objects mapped by Hibernate entities
* have the expected definitions.
*/
void validateMappedObjects();
/**
* Truncate the database tables mapped by Hibernate entities, and
* then re-import initial data from any configured
* {@linkplain org.hibernate.cfg.AvailableSettings#JAKARTA_HBM2DDL_LOAD_SCRIPT_SOURCE
* load script}.
*/
void truncateMappedObjects();
}
Of course, validateMappedObjects()
and truncateMappedObjects()
might not be features you folks want in the JPA spec, since JPA doesn't have any such functionality defined today.
Folks, please review https://github.com/jakartaee/persistence/pull/431
If we decide to do this, and if SchemaManager
has a validate()
method, then I think we should also list "validate"
as one of the allowed values for schema export config. It would have fairly weakly-defined semantics (and providers could even just ignore it) but even so it's worth enumerating I believe.
(Note that validate
is a lot less problematic than update
, so I'm not really contradicting myself here.)
For testing, it's quite useful to have a programmatic way to perform schema management, instead of messing about with properties and creating/destroying the
EntityManagerFactory
.