A more general question, for which I hope the answer is "read this document"; I just haven't found it yet.

I'm getting ready for the first alpha of my product; from that point forward, I would like to keep my DB pretty much live, without wiping it and starting again. However, I expect to be modifying the product frequently -- indeed, constantly -- for at least the next year, and those modifications are often going to hit the DB schema.

So the question is, within the Hibernate framework, what's the best way to manage my schema evolution? My system is Hibernate-centric at this point: I actually started with the HBM files, because I'm very comfortable working in that sort of metadata and going outward in both directions from there. But the documentation I've found so far says little about schema evolution, except to imply that it's dangerous to use Hibernate's automated schema-modification mechanisms in a live production DB.

How do people deal with this? Do I need to simply keep track of my schema changes, and write manual ALTER TABLE commands to apply them as I roll out subsequent iterations? Use the automated tools, but manually vet its suggestions for changing the DB? Obviously no automated tool can possibly cope with major structural changes, but it would be nice if Hibernate can make life easier for easy changes like adding new columns.

I'm hoping that there are at least established best practices for how to manage this, since I expect to be doing quite a bit of it, rolling out revs every month or two. Thanks for any suggestions...

Hey,

I decide to generate alter script by using TOAD compare schema's.
TOAD can show you the diff and generate the alter.

if you found another solution i will be happy to read about it.

I rely on manually-generated ALTER TABLE scripts. I'm currently evaluating using Liquibase for this.

You may also be interested in the Hibernate functionality that has recently been added to LiquiBase. See http://www.liquibase.org/manal/hibernate.

The new feature allows a combination of hbm2ddl-like functionality along with the control you get over manual alter scripts.

Basically, there is now a LiquiBase command that will compare a hibernate mapping config and an existing database and automatically append the required changes (add table, add column, drop column etc). You can then simiply run the changelog file as it is or modify it as needed.

And since it is a standard LiquiBase change log file, you get all the other LiquiBase functionality such as the ability to tag and rollback changes, generate change documentation, and more.

i am working with JPA (hibernate is the implementor).

It should work fine. The LiquiBase diff engine uses hbm2ddl as a base which I think supports JPA annotations.