DataNucleus JIRA is now in read-only mode. Raise any new issues in GitHub against the plugin that it applies to.
DataNucleus JIRA will remain for the foreseeable future but will eventually be discontinued

to create and validate a schema. But when during unit tests and development, it is sometimes desired to drop a schema during startup because the update mechanism of the autoCreateSchema does not do the job. So it would be nice to have a "datanucleus.dropTables" property, which ensures that tables get dropped before being created again by datanucleus.autoCreateSchema.

I tried writing my own kind of hook by using the SchemaTool API, but that brought me all sorts of exceptions and bad behaviour.
- For example it telling me to enable "datanucleus.autoCreateTables" to be able to drop a table that does not exist.
- Or "datanucleus.autoCreateTables" created its tables when being enabled (useless waiting time), then my hook called deleteSchema, which succeeded and cleaned the schema. But the createSchema that followed threw an exception about not being able to map BigInteger...
- Also it is kind of bad that one has to give SchemaTool paths to class files instead of just giving it class names as a fqdn (the class name on the classpath) each.

Also, the deleteSchema (through SchemaTool and the desired datanucleus.dropTables feature) should delete the sequence table aswell. When I had hibernate and datanucleus use the same table name for the sequence table, datanucleus wouldn't want to reset it and just failed on trying to get a new id because the table has different columns.

If you don't want to add such a feature, I will have to make the SchemaTool get working, which means I'll have to submit all the bugs I encountered and I'm going to encounter with it separately...

Description

There is already:
datanucleus.autoCreateSchema
datanucleus.autoCreateTables
datanucleus.autoCreateColumns
datanucleus.autoCreateConstraints
datanucleus.validateTables
datanucleus.validateColumns
datanucleus.validateConstraints
to create and validate a schema. But when during unit tests and development, it is sometimes desired to drop a schema during startup because the update mechanism of the autoCreateSchema does not do the job. So it would be nice to have a "datanucleus.dropTables" property, which ensures that tables get dropped before being created again by datanucleus.autoCreateSchema.
I tried writing my own kind of hook by using the SchemaTool API, but that brought me all sorts of exceptions and bad behaviour.
- For example it telling me to enable "datanucleus.autoCreateTables" to be able to drop a table that does not exist.
- Or "datanucleus.autoCreateTables" created its tables when being enabled (useless waiting time), then my hook called deleteSchema, which succeeded and cleaned the schema. But the createSchema that followed threw an exception about not being able to map BigInteger...
- Also it is kind of bad that one has to give SchemaTool paths to class files instead of just giving it class names as a fqdn (the class name on the classpath) each.
Also, the deleteSchema (through SchemaTool and the desired datanucleus.dropTables feature) should delete the sequence table aswell. When I had hibernate and datanucleus use the same table name for the sequence table, datanucleus wouldn't want to reset it and just failed on trying to get a new id because the table has different columns.
If you don't want to add such a feature, I will have to make the SchemaTool get working, which means I'll have to submit all the bugs I encountered and I'm going to encounter with it separately...

Andy Jefferson added a comment - 03/Aug/11 02:47 PM SchemaTool is the place for any feature of that sort and it's low priority for me.
Saying you get some error or other is of no value (to the project) since you don't quote input+operation+error, so perhaps just best concentrate on this feature.

Since SchemaTool has the option of deleting all tables for the input classes, then I don't see why that doesn't fulfil this requirement. If you have some issue with some particular input+operation with SchemaTool then that needs raising as a separate issue WITH TESTCASE.

Andy Jefferson added a comment - 04/Apr/12 06:07 PM Since SchemaTool has the option of deleting all tables for the input classes, then I don't see why that doesn't fulfil this requirement. If you have some issue with some particular input+operation with SchemaTool then that needs raising as a separate issue WITH TESTCASE.