What happens to data in a hibernate database if the format of the objects are changed

• Search hibernate forum for change
  • Changing HBM dynamically at runtime - https://forum.hibernate.org/viewtopic.php?f=1&t=992208&p=2437055&hilit=change#p2437055
    • Once the SessionFactory has been built, you can't make any configuration changes to it. You'll need to create a new SessionFactory from scratch

See Avoidance of hbm2ddl.auto=update in production

• update scripts that Hibernate would create will add new fields to a database but will not delete existing columns (even if these have been removed from the annotated entity). It makes a good deal of sense not to delete columns from a production database without knowing exactly what you are doing so this is a good thing!

hbm2ddl.auto is mentioned in http://docs.jboss.org/hibernate/core/3.3/reference/en/html/session-configuration.html

How to monitor changes that Hibernate wants to make:

• Do all changes in development/staging mode and transfer and execute scripts in production manually (or automatically, but don't let hibernate run them). The scripts may need some tunning since hbm2ddl update does not cover all cases. In fact I never let hibernate run ddl against any database. I use hbm2ddl to generate text: org.hibernate.tool.hbm2ddl.SchemaExport --config=hibernate.cfg.xml --text --format --delimiter=; org.hibernate.tool.hbm2ddl.SchemaUpdate --config=hibernate.cfg.xml --text --format --delimiter=;

I wish to pass to Hibernate's SessionFactory

• hibernate.hbm2ddl.auto=update
  and see in log file generated sql statements. Is it possible w/o java coding (know how to achieve the result with SchemaExport, but hope that hibernate has "in box" solution)

You could setup logging to System.out using

• SessionFactory sf = new Configuration().setProperty("hibernate.show_sql", "true")
• or log4j
  • log4j.logger.org.hibernate.SQL=DEBUG, SQL_APPENDER
  • log4j.additivity.org.hibernate.SQL=false

Unfortunately, hbm2ddl ignore both options. So I don't see any alter/create statement in my log file.

@FoxyBOA for ddl statements you should try : log4j.logger.org.hibernate.tool.hbm2ddl=debug

How to stop hibernate database objects from being deleted on every application start

• change this line to "validate" instead of "create" and you'll be fine.
  • Code:
    • <prop key="hibernate.hbm2ddl.auto">validate</prop>
  • [create] means that with every init of the Session Factory all tables will be dropped and recreated.
  • [validate] means that with every init of the Session Factory the schema will be validated against your annotations/hbm.xml files

How to update a database scheme with hibernate link

• http://www.liquibase.org
  • Problem with updating databases with diff's - http://blog.liquibase.org/2007/06/the-problem-with-database-diffs.html
• use the hbm2ddl ant task to generate my ddl. There is an option that will perform alter tables/columns in your database. See the "update" attribute of the hbm2ddl ant task: http://www.hibernate.org/hib_docs/tools/reference/en/html/ant.html#d0e1137
• http://www.chronicdb.com
• use SchemaUpdate, which is built in to Hibernate, straight from a bootstrap class so the schema is checked every time the app starts up. That takes care of adding new columns or tables which is mostly what happens to a mature app. To handle special cases, like dropping columns, the bootstrap just manually runs the ddl in a try/catch so if it's already been dropped once, it just silently throws an error. I'm not sure I'd do this with mission critical data in a production app, but in several years and hundreds of deployments, I've never had a problem with it.
• http://code.google.com/p/dbmigrate/ - DBMigrate - Similar to 'rake migrate' for Ruby on Rails this library lets you manage database upgrades for your Java applications.

Another idea I thought of:

• When a copy of the app is put into production, maintain a copy of the objects and mappings that went with it.
• Later when a later version, with different objects needs to go into production, write a converter. Include all the old objects to allow them to load the data from the database, and write java to create a new database with the new object format, and then load all the old objects, and transfer the data to new objects on the new database.
• I haven't actually tried this, and it is probably a lot more trouble than its worth, especially with a large database.

google queries:

• hbm2ddl.auto
• when not to use hibernate