I am seeing an interesting issue that made me wonder about the mapping files produced by Hibernate Tools.

I am using Beta2 and getting an exception when Hibernate 3.0.5 is populating the Hibernate Tools Generated java POJO's. Seems Hibernate is trying to populate a field such as long (default type produced by Hibernate Tools when the database value is a null into a primative java type long in the POJO.

When I used middlegen I noticed it produced information regarding nullable fields in its mapping files and noticed the mapping files produced by Hibernate Tools does not do this. I figured this is a critical issue about setting primatives to null and must be covered by Hibernate itself when it populates VO's generated by the tools.

So, does Hibernate itself use reflection to avoid this issue of trying to populate primatives with NULLs or should the mapping files produced by beta have info regarding nullable fields for Hibernate to use? If so should I use some setting I am not using to put nullable info in the mapping files? This nullable info should be auto generated otherwise for large databases manual entry of mapping info would be time consuming thus not practical.


Thanks,
-Tony

I now have more info on this interesting issue.

It looks as if Hibernate is generating an exception when I read a field in an hibernate tools generated object.

It looks as if Hibernate is using lazy loading when you read a field in a Hibernate Tools generated VO after it was used in a session object. Since the field read is null and the destination field is a primative an exception is thrown. I copied the exception below.

org.hibernate.PropertyAccessException: exception setting property value with CGLIB (set hibernate.cglib.use_reflection_optimizer=false for more info) setter of com.test.mappings.hibernate.TableB.setSystemId

Hibernate Tools group - Any ideas what I should do?

Thanks,
-Tony

Even more interesting answer to why this is going to be a big issue for Hibernate Users.

It appears the exception in my last post the hibernate exception and my knowledge of the data at the time of the exception has given me a reason to beleive there is a BIG ISSUE with Beta2 of Hibernate Tools.

I remember in Alpha5 of the Hibernate tools that by default the data fields in the database where they used NUMBER with no scale were set to a Wrapper such as Long. With Beta2 I noticed the default is the primative long. Now read the following explanation of the exception below:


public class PropertyAccessException
extends HibernateException
A problem occurred accessing a property of an instance of a persistent class by reflection, or via CGLIB. There are a number of possible underlying causes, including

failure of a security check
an exception occurring inside the getter or setter method
a nullable database column was mapped to a primitive-type property
the Hibernate type was not castable to the property type (or vice-versa)


Author:
Gavin King
See Also:
Serialized Form


Voila! Exception thrown in my case because the value read from the database is null and mapped to a primate long. Guess what this is typical for databases to allow for nullable fields.

There are several solutions:

1. Change the tools back to use Long instead of long by default.
2. Using reverse engineering change all the longs to Long
3. Add capability to tools if not already exisitng to use Long instead of long for fields where they can be null.


I will probably have to use option 2 for now if I can get it to work.

Hopefully the Hibernate Tools team (Max) reads this soon.

Regards,
-Tony

#3 is what make sense to me.

Could you add it to jira and i'll add it before the bugfix release next week.
The fix is just to have nullability passed on to ReverseEngineeringStrategy.columnToHibernateTypeName and if true, return non-primitive types.

Hi Max,

Thanks for the reply I really appreciate your help.

Is there going to be a working example of what you are talking about?

I am interesting in getting this working. So far through a little more effort than I expected I have the following working for me using beta2:

1. Exclusion of tables from the reverse engineering.
2. Changing of java data type.

I have not been able to get the setting of the data types through type-mapping but of course I can now through table specific mapping which is not efficient for the use case I mentioned.

If I can get an example of what you are talking about through a step by step example would help everyone. I have questions about how I compile the custom strategy for example one written so it can be used.

I will try to find the updated documention if you let me know which cvs to look at. I went to the JBoss one but could only get the binaries.

Also, how do I do the rate you mention?


Thanks,
-Tony

users seem to have big problems with doing the type mappings where as i dont have these issues with oracle and hsqldb...i'll need to investigate this to help better.

The updated doc is in the hibernate cvs under hibernateext/tools. Look at tools.hibernate.org under Build & Contribute to see details.

http://opensource2.atlassian.com/projec ... se/HBX-532

reverse engineering now takes nullability into account before choosing a hibernate type.

Hi Max,

Again thanks for your very fast response.

When can I get this enhancement? When is beta 4 going to be available??
I downloaded the nightly builds on Monday and did not fix the problem but not sure if the fix is only available in beta 4.


Thanks,
Tony