hbm2java generates the POJO code from mapping xmls. Is there a way to specify somewhere (like some properties file), to use a different name for the generated class file instead of the one specified in the mapping file?

We have a major concern like after developing our application using hibernate, if there are some changes to database layout or change in column names or table names etc, how it is going to impact the developed application?
We feel that this should be one of the features any ORM tool has to provide. Like simple changes to database not impacting the developed application.

Mainly we want to cover the following cases.
1. Changing a column name of a table
2. Changing the table name.
3. Adding new columns to a table.
4. Move columns from one table to another (both having a common key)
5. Make Rows of one table as columns of another.
(This needs more explanation ... example, lets say we have two tables,
Order, Order_items

Order - Order_id, Item_id, Customer Info (columns)
Order_Items - Item_id, Item_name, no_of_items

Values for Item_name - Milk, Eggs, Butter, etc.
Fow whatever reason, lets say, we want to add Milk, eggs as columns
to the order table.

New order table:
Order - Order_id, Item_id, Customer_Info, Milk, Eggs

________________________________

In all the above cases, if we use Middlegen + Hibernate, the generated class files obviously will have different field names and maybe different class file name (if the table name gets changed). And then we have to modify our application wherever these classes are used!!!! This doesnt sound logical. We feel there should be a way and ORM tool should be able to handle these cases making it transparent to our application code.

Any hints of how this can be handled would be appreciated...
We are thinking there should be a properties file (SIMILAR TO THE WAY JAXP HAS), where we can specify the old name to new name mapping and the class file generator generates the files using the old name instead of new name!!!

Torque claims to do this.

Hmm,... very bad.. no replies till now..

Does anyone ever look at this forums and reply?

I have another concern...


The physical data layer(Database) should be flexible enough to allow subtle differences primarily for performance or db specific implementations that you don't want creeping into the logical model. If hibernate is incapable of allowing us to encapsulate physical implementation from the object/business layer, then it seems to me that it doesn't meet the criteria for an ORM tool.

Given the number of posts to this forum every day, I would say that the answer to that question is: yes.

I'm not a hibernate 'expert', but from my experience, here is my take on your concerns:

Cases 1 and 2 can be handled by modifying the class and property values in your hibernate configuration files. No changes to application code.

Case 3 should be transparent to hibernate. I don't remember seeing hibernate use any 'SELECT *' statements (somebody correct me if I'm wrong here), so new columns should not affect the application -- unless you've got a NOT NULL constraint or some such on the new column.

Cases 4 and 5 are going to require application changes of some sort, even if you just interpose a new class between hibernate and the application code that manipulates things so that the application code doesn't notice the difference. Putting on my DBA hat, I would say (IMHO) that these two cases represent non-trivial changes in the logical data design, so application changes should be expected.



There are a number of things that you can muck with at the database physical level that hibernate will be blissfully ignorant about. That's part of what a relational database engine delivers. However, what you're talking about is changing the metadata (i.e. logical model) of the database, and you can only do so much of that before applications are affected.

If you do find an ORM tool that handles all of your cases, reply back here. I'd be interested in seeing just how it handles cases 4 and 5.

Oh, one other thing I forgot to mention... depending on the database you're using, you might be able to handle cases 4 and 5 with database views and stored procedures/triggers, etc. If so, then you could get away without changing your application code.