Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Hibernate - Generated POJO code

 
Krishna Radha
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Krishna Radha
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmmm.. Hit enter before completing my post. Adding more details here...

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.
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

to use a different name for the generated class file instead of the one specified in the mapping file

The hibernate mapping would not work if you did this. If the mapping specifies one class, and you've renamed it Hibernate will fall over with a ClassNotFoundException or somethig simmilar.

As to all your other requirements:
1. Just change the name of the column in that mapping file. That's a big reason why you use a mapping file in the first place.
2. Again, just change it in the mapping file. If you want to keep the old POJO name, don't use middlegen. Or edit the files after middlegen has created them.
3. I you want your new columns included in the app, then you will have to add them to the mapping and POJO. There are tools avaliable from Hibernate which will generate these based on the current schema.
4. Again, just change the mapping.
5. Not sure what you mean here.

There is no ORM tool avaliable which will adapt itself transparently as the schema changes. However, many (including Hibernate and Torque) offer round-robin generation tools. Have a dig around the Hibernate site to see them all.
[ June 09, 2004: Message edited by: Paul Sturrock ]
 
Krishna Radha
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For any of the five database changes I mentioned above, we can always modify the mapping file as you suggested. But in this case, everytime we regenerate our mapping files, we have to always remember our changes and edit them manually. Instead if we have a properties file to specify all our manual changes which we wanted in the mapping file, then maintainence would be easy. It sounds logical. Jaxp uses a similar properties file. Not sure if hibernate has any such properties file!!!
 
Krishna Radha
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
quote:
--------------------------------------------------------------------------------

to use a different name for the generated class file instead of the one specified in the mapping file
--------------------------------------------------------------------------------


The hibernate mapping would not work if you did this. If the mapping specifies one class, and you've renamed it Hibernate will fall over with a ClassNotFoundException or somethig simmilar.


I was not saying we would manually change rename the class file. I was asking if hibernate provides any such provision to read the mappings and the properties file together to generate the class files. This way all our manual changes which we can be done in mapping file, we can have them in a seperate file and hibernate can use this two files together while generating POJO files.
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

This way all our manual changes which we can be done in mapping file, we can have them in a seperate file and hibernate can use this two files together while generating POJO files.

The architecture of Hibernate relies on the integrity of the mapping files. If you are changing them on the fly, you can't expect Hibernate to work.

As I said before, there are round-robin tools avaliable with hibernate which will geenrate all you need based on a schema. I'd have a look at these. Personally, I don't see a need to support things like table name changes in an ORM - assuming you have modelled the data well to start off with, its very unlikely (in my experience) that you will be making changes as dramatic as renaming tables, which is the only semi-awkward change you are looking for. As for adding/renaming columns this will be frequent enough during development but not really that awkward. And remember the Hibernate round-robin toolset allows you to use the mapping files as the DDL.
[ June 09, 2004: Message edited by: Paul Sturrock ]
 
Krishna Radha
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are right.. Table name changes might look somewhat awkward. I had that just to cover all the cases and wanted to know how this all can be handled.

3. If you want your new columns included in the app, then you will have to add them to the mapping and POJO. There are tools avaliable from Hibernate which will generate these based on the current schema.


Middlegen does the job of generating the mapping with new columns. But in this case, if the generated POJO has new data members, doesnt it impact our application code which was using the old POJO.
So in this case do we need to revisit our application code to modify as per the new POJO files? Answer to this is probably yes.

So can I assume that other than the mapping files, hibernate doesnt look for any properties file? And if we want to retain the old names for the data members in the POJO file, there is only one way of doing it (manually editing the mapping file)???

Hmm.. I was really lookin to have a file where we can specify our manual changes so that everytime we need not edit the mapping files.
 
Krishna Radha
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
5. Not sure what you mean here.



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, Customer_name, Customer_phone
Order_Items - Order_id, Item_name, no_of_items

Values for column Item_name - Milk, Eggs, Butter, etc.

To get the complete order information, we need to join both the tables.

Example data :

Order
============
Order_id Customer_name Customer_phone
10454 Guilermo marin 8292323232

Order_items
============
Order_id Item_name No_of_items
10454 Milk 5
10454 Eggs 10


For whatever reason, lets say, we want to add Milk, eggs as columns
to the ORDER table.

New ORDER table:
Order - Order_id, Customer_name, Customer_phone, Milk, Eggs

Here instead of joining two tables, we are having one table with all the items as columns, the values of which will be the nummber of those items ordered.

For example, one entry in order table looks like

Order
============
Order_id Customer_name Customer_phone Milk Eggs
10454 Guilermo marin 8292323232 5 10


_______________________________________

After designing our tables as in the first case, we develop our application. Now we change the Order table structure to store the data in one table. Is it possible to make this change transparent to the application having some customized code in between which takes care of transformation?

Our major concern is any changes to the database shouldnt impact the application code developed based on the POJO code.
For this, we were also thinking of possiblity of having some customized code developed on the generated POJO files which will make the application code transparent to any changes in the database or the POJO code.
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes adding new properies will impact your application, presuming you want to actually use the new properties. However if you don't change the POJO name, adding new properties won't cause any problems in the application. Which is one of the reasons for an ORM layer. Changing the name of a POJO will incurr the same refactoring costs of changing any Java filename in an application. There is no way round this.

As I said above, there is a single point where you can manage the possible changes made to either the POJOs or the schema, and that is the mapping files themselves. Their whole purpose is to manage the relationship between the Java classes and the schema so this is the logical place to be trying to do this anyway. What to change the name of a POJO? Then rename the class in its .hbm.xml file and regenerate the POJO. Want to change an aspect of the schema? Change the table/field names/properties in the mapping files and regenerate the schema using the new mapping. I can't see any benefit to be gained from making such changes in a separate properties file, but I can see it complicate Hibernate's otherwise simple architecture and introduce yet another source for errors.

As for your example of point 5. (without wanting too sound rude) - denormalizing the entities like that is just bad ER modelling. And again, changes like this should not happen (or at least will be kept to the absolute minumum) if enough time is taken to model the schema properly in the first place.
[ June 09, 2004: Message edited by: Paul Sturrock ]
 
Krishna Radha
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The benefits of having a properties file is we can have all our manual changes mentioned in that once and we can regenrate the mappings file as many times.
If we manually edit the mappings files, again and again we need to modify the mappings file whenevr they are regenerated. And again we need to remember all the changes we are doing to that mapping file. And if the mapping file is regenerated, all our changes are lost!!!
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

mappings file whenevr they are regenerated.

*Sigh*. Krishna Radha I have already mentioned twice that you don't need to ever regenerate the mappings files if you use them as your DDL. If you don't want changes made to them to be lost then don't run middlegen! Its as simple as that. Hibernate supplies round-robin tools to generate both the POJO and the Schema from these mapping files. So the sensible place to manage changes to either, is there.
[ June 09, 2004: Message edited by: Paul Sturrock ]
 
Krishna Radha
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
what are the round robin tools that hibernate supplies? For generating mapping file from DDL, we use Middlegen. And from mapping file to DDL, we can use hbm2ddl. Are there any other useful tools you are talking about?
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
AndroMDA, XDoclet, SchemaExport, Middlegen, CodeGenerator etc. Have a look on Hibernate's site, you'll find them and more. SchemaExport and CodeGenerator are all you need.
 
Krishna Radha
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also 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.
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

encapsulate physical implementation

This is the same question you have asked a number of times Krishna Radha. And I've answered it a number of times.

Krishna Radha its becoming clear that you only seem to be asking this to nit pick at Hibernate. Fair enough, it - like all software - is not perfect. If you are so unsure about its capabilities, then don't use it. I am not going to argue with you about which is the best ORM tool. There is enough literature on the web to demonstrate that Hibernate is good enough for many people, and Sun's planned adoption of its design for the ORM layer of the next EJB spec release should give you a hint that people are happy enough with it.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic