Currently, the SchemaDefiner contract is implicitly invoked during bootstrap. Instead, we should consider the setting given for the "hbm2ddl" option and initialize/drop the schema accordingly.
In addition, JPA 2.1's Persistence#generateSchema() operation should be supported.
This will require to add a dropSchema() method to SchemaDefiner.
Also the property OgmProperties#CREATE_DATABASE seems obsolete once we support hbm2ddl.
, do you think you could take a look at this one? It'd be nice to get this done for the Final. Note that support for Persistence#generateSchema() can be done separately IMO.
Bummer, so you guys decided against doing this for the Final :-/ ? Would have been very useful IMO as we now have an option which we'll remove for sure in 4.2.
This turned out not to be trivial to do and will require changes in Hibernate ORM.
Basically hbm2ddl does trigger the SessionFactory to call SchemaUpdate (or something like that). Davide tried to fool this mechanism but we could not find a way,
So we need to take a step back and modify ORM first.
The problem is in SessionFactoryImpl, the creation of a new SchemaExport is done in the constructor of SessioFactoryImpl when the hbm2ddl property is set. The schema export fails because it runs org.hibernate.cfg.Configuration.generateSchemaCreationScript(...) and it cannot recognize some types. This is the error:
I've tried to override the methods in OgmConfiguration but I still have the error if Persistence.createEntityManagerFactory(...) is used.
This finally will be doable as of ORM 5.1 with the required changes implemented as part of HHH-10458.
What we'll have to do:
Implement an OGM-specific SchemaManagementTool and its delegates
Drop properties "hibernate.ogm.datastore.create_database" (replaced by "hbm2ddl.auto") and likely "hibernate.ogm.datastore.database" (I suppose "hibernate.default_schema" can be used instead)
Add support for dropping tables etc. -> add List<T> getDropCommands() to SchemaDefiner where <T> is a store-specific type of DDL commands (mostly String, but it may be some object representation e.g. for MongoDB which does not have a DDL)
The schema management mechanism supports different types of "targets": DATABASE, SCRIPT and STDOUT; In a first step OGM would only support the former; Naturally, the other two require DDL commands to have a String-assignable representation, so they may not be doable for some backends
Further steps will include
Support for reading import scripts (SourceType.SCRIPT etc.); Again the String-requirement may make it not supportable for some stores
Support for the other hbm2ddl modes (validation, migration)
I've pushed a very rough first attempt to my fork at https://github.com/gunnarmorling/hibernate-ogm/tree/OGM-571; This is far from being complete, just a validation to make sure the work on the OGM side suits our purposes