Generating Hibernate hbm xml files & entities classes from existing DB schema

Question

How can I generate Hibernate hbm xml files & entities classes from an existing DB schema?

Answer 1

I've used Hibernate Tools (examples given on their site) with much pleasure. Below, I give details on my specific, advanced and interesting (I think) use case.

---

Actually, I was facing an interesting challenge on our big project (approaching 800 tables, database driven team)

• New tables would keep arriving, so I could generate them from the database (using HibernateTools, and producing Annotated Entities)(we're actually using another process right now ...)

• But mosts tables were not new, I already had the java implementations and the .hbm.xml. Both had sometimes been modified from the DB they were originally generated with, so it was impossible to re-generated them with the guaranty not to break anything. I needed to migrate the Entities, changing as little as possible (that is, only the annotations) !

  • This needed to be fast also, because our typical old entities have around 100 members (own db columns, plus entity collections coming from reverse foreign keys!).

    Note : Two entities couldn't compile with a generated full-constructor, they broke the 256 parameters limit ! But I though this Constructor was useless anyway, who could remember the order of 256 parameters, so I removed it.

  • I also wanted to migrate my Sets to generic ones (except the setter I didn't bother with for now).

For the mapping migration, I used Hibernate Tools (customized as needed, template and code) as follow:

• the source of the information was the .hbm.xml files, with the hibernate.cfg.xml file

  Note : I had to extract the hibernate.cfg.xml first, replacing the spring bean that used to contain the list. But this was also useful for db tools such as Squirrel, that could use it to enable HQL completion...

• the generated output was X2.java files (for X.java class, in the same package) containing only the fields, getters and annotations (no setters or constructors)(generic Sets)

I would use the Eclipse compiler (error "duplicate ...") to double-check my editing, to make it faster and less error-prone (mistake was not an option, we have many client in production !). For each migrated class, I would copy from generated to existing class :

• change persistence.cfg.xml to use the class instead of the .hbm.xml
• cut and paste @Entity before class name
• cut and paste all Set fields after existing fields, delete only the existing ones that have a compile-error (the result is that I now have fields with generic Sets)
• cut and paste all getters (which is the rest of the class) after the existing setters
• open the outline view, showing only public dynamic methods not starting with 'set', sorted alphabetically
• check each getter that has not error (investigate if something went wrong, or it had been dropped since ...)
• following the outline view, considering only erroneous methods, for each getter in order : delete the second instance of the method, copy its annotations to the first instance (navigation using the outline view)(the order of the methods in the class is preserved, which has been important for CVS history, notably in proving to unbelievers that the migration didn't break their code, it was already broken before !).
• ... some details left for further discussion ...

For the curious, this month we're close to 200 annotated entities :-). A typical 100 fields entity requires about 30 minutes work to migrate. Only 300 hours left to finish this cut'n paste for the remaining 600 entities ! ;-)