I enjoyed using the Hibernate Tools (examples provided on their website). Below I will talk about my specific, advanced and interesting (I think) use cases.
Actually, I had to face an interesting task in our large project (approaching 800 tables, a database-based team)
- New tables will keep coming, so I could generate them from the database (using HibernateTools and creating annotated objects) (we are actually using a different process right now ...)
But most tables were not new; I already had java implementations and .hbm.xml. Both of them were sometimes modified from the database originally created, so it was impossible to re-create them with the guarantee not to break anything. I needed to transfer objects as little as possible (i.e. only annotations)!
It should also be fast because our typical old objects have about 100 members (native db columns, as well as entity collections coming from reverse foreign keys!).
Note. Two objects cannot compile the generated full constructor; they violated the limit of 256 parameters! But I, although this constructor is still useless, who could remember about 256 parameters, so I deleted it.
- I also wanted to transfer my sets to general ones (with the exception of the setter, on which I was not worried).
To migrate the display, I used Hibernate Tools (customizable, template and code as needed) as follows:
the source of information was the .hbm.xml files with the hibernate.cfg.xml file
Note. First I needed to extract the hibernate.cfg.xml file, replacing the spring bean that was used to store the list. But it was also useful for db tools like Squirrel, which could use it to complete HQL ...
the generated output was X2.java files (for the X.java class, in the same package) containing only fields, getters and annotations (no setters or constructors) (common sets)
I would use the Eclipse compiler (error "duplicate ...") to double check my editing, make it faster and less error prone (the error was not an option, we have many clients in production!). For each migrated class, I would copy from the generated to the existing class:
- change persistence.cfg.xml to use the class instead of .hbm.xml
- cut and paste @Entity before the class name
- cut and paste everything. Set fields after existing fields, delete only those that have a compilation error (as a result, I now have fields with shared sets)
- cut and paste all getters (which is the rest of the class) after existing setters
- open a diagram view showing only publicly available dynamic methods not starting with 'set' sorted alphabetically
- check every recipient who has no error (research, something went wrong, or it has been reset since ...)
- following the contour view, taking into account only erroneous methods, for each getter in order: delete the second instance of the method, copy its annotations into the first instance (navigation using the outline) (the order of the methods in the class is preserved, which was important for the CVS history, especially in the proof to unbelievers that the migration did not violate their code, it had already been violated before!).
- ... some details remain for further discussion ...
For the curious this month, we are approaching 200 annotated objects :-). For a typical 100-field object, it takes about 30 minutes to migrate. Only 300 hours left to finish this clipping for the remaining 600 objects !; -)
KLE
source share