12

Allowed values for javax.persistence.schema-generation.database.action are

  • none (that doesn't serve anything...)
  • create (which only works the first time the application is started because all further starts fail due to most databases (e.g. derby 11.x) fail if a schema that already exist is created
  • drop-and-create (which wouldn't ever persist any data which raises the question why it's part of a persistence standard specification - assuming debugging purpose)
  • drop (symetrically fails create succeeds

which leaves absolutely no option to use any of these value nor do I see any sense in their specification - assuming you don't want the user of your application to start the application once (with create), hack the persistence.xml file, repackage you application and use it with none. How to use them to persist Java objects accross application restarts, then?

I know about Hibernate's hibernate.hbm2ddl.auto which works great, but I'm trying to get the mystery solved for a JPA 2.1 implementation portable approach.

Kalle Richter
  • 8,008
  • 26
  • 77
  • 177

1 Answers1

12

Hardly any mystery (and they are defined in the spec, or in the docs for any decent JPA implementation). This is run when the EMF is created (or as a separate up front operation if invoked via Persistence.).

"none" means do nothing ... so do like JPA has always done things i.e just persistence. It isn't there to "serve any purpose", just to not do anything extra!

"create" means create the tables for the entities (so it is assumed to not exist yet). Clearly most JPA providers will check existence of tables before creation, so it won't "fail on subsequent uses".

"drop" means drop the tables for the entities (so when running as stand alone process, clean up after tests for example).

"drop-and-create" drop and create the tables for the entities, so get rid of what was there and start from scratch. Nothing to do with persisting data, but then none of these options are.

As said, some of these options are most useful for testing. In a real world situation most people would generate DDL, refine it to meet their DBAs requirements, and generate it manually, then just run JPA hence no use this property at runtime

  • true enough, but it is still a little server/JPA vendor specific. For example on Glassfish 4+/Payara I've noticed that schema generation doesn't really trigger until you completely undeploy and redeploy the application. – Gimby Dec 24 '15 at 08:47
  • Thanks for the explanation. If the effect of `clear` depends on the JPA provider, then there's no definite cross-provider approach, right? – Kalle Richter Dec 24 '15 at 16:09
  • @Karl Richter, what do you mean by clear? clear the database of tables? –  Dec 25 '15 at 07:37
  • Is it correct that you can use "create" and won't fail on subsequent uses? Does this apply to Derby? – sdbol Jun 19 '17 at 12:16
  • I do agree with the verdict that those options are mostly useless. e.g. what happens if there are constraints within the data? Do they get disabled first before dropping the tables? Initially this chapter was designed for the first EE7 'Java EE for Cloud' proposal which got scrapped later - for good reasons. Pretty much only the JPA sections did remain. Only minimal useful part is to use 'javax.persistence.schema-generation.scripts.drop-target' to write the SQLs to a file. But every JPA provider can do that anyway in proprietary ways. – struberg Jun 14 '21 at 13:00