Hi, Emmanuel,

Thanks so much for you work on Hibernate annotations. It's making maintaining our mappings *so* much easier.

One of the features of HibAnn I haven't been able to get working yet is the automatic support for Java 1.5 Enums. I'm using Oracle 10g, Hibernate 3.1 beta1, and Hibernate Annotations 3.1 beta4. EnumType is currently failing to determine the correct backing sql type for our enum properties and is defaulting to treat it as an integer. Unfortunately, nearly all of our enums are represented by their string names. It's not a hugely pressing issue; I've got workarounds with my own EnumUserType class and the appropriate type declarations. However, getting this feature working would be awesome.

So, the problem I'm facing is in getting the correct "schema" into EnumType. In EnumType.guessType, there's the following call to retrieve the column meta data:



In our setup, 'schema' is null; we don't specify it on any of our tables. Unfortunately, a null schema used with getColumns returns information for every 'user' in our Oracle db. We tend to have multiple copies of our schema in Oracle, each associated with a different username, and the schema for these instances is the same as the associated username. So, even though each of these table/column combos have the same type, the current implementation of 'guessType' will because there's more than one row in the resultset. If I hardcode a schema into the Table annotation, the lookup works. Unfortnately, hardcoding a schema into the annotations isn't an option, because we have multiple oracle installations (dev, test, production) each with their own usernames/schemas.

I've tried several approaches to getting the schema into EnumType programmatically, but none of them worked:

• Neither EnumType nor AnnotationBinder (which configures the EnumType) honors the hibernate.default_schema setting.
• I created a custom annotation and Hibernate Validator that implemented both PropertyConstraint and PersistentClassConstraint. The apply method for both intf's was implemented to get the table and set its schema. I added this annotation at both the property and class level, and while my apply methods were called, they were called *after* the enum property itself had been initialized, so it didn't see the updated schema.
• As a last-ditch effort, I tried to set @Column.columnDefinition property to be a VARCHAR, but EnumType didn't honor this setting, either.

At this point, I'm stymied. I don't know if there's some configuration of either Hibernate or Oracle that will produce the results I want, or if this is an actual bug in Hibernate annotations. If this is a shortcoming of EnumType, I can think of some possible changes that would help this problem:

• If there are multiple rows returned from the above call, don't fail immediately. EnumType could check if all the returned rows have the same DATA_TYPE, and if so, use that. If this is an acceptable solution, I would enter a JIRA issue and submit a patch.
• Honor hibernate.default_schema setting if no schema is otherwise specified. I'm not sure how to implement this, if this would be in AnnotationBinder or EnumType, and how it would get access to this setting. But it seems like a reasonable thing to do, regardless.
• Try to discern the backing type from @Column.columnDefinition, if specified. Not sure if this is an acceptable solution, or if this is an appropriate use of this annotation. Just an idea.
• Process validators before normal annotations. Again, this might not be a reasonable change, nor would I know how to go about making this change even if it were. But the current ordering makes it impossible to change a schema through a validator in time for EnumType to recognize it. Perhaps this is just the way it has to be...

I'm also open to other suggestions. I've tried to do as much investigation as possible before creating this post, but I almost certainly may have missed something.

Thanks for any suggestions you may have. Let me know if you need any further information.

Thanks ;-)


I guess I should implement that it makes a lot of sense. Open a JIRTA issue.

Interesting. Actually EnumType is a weird case since we need some metadata and some DB access to discover the type wich is quite unique for an hibernate type. Open a Jira issue too I need to check if I can tweak the enumtype parameters to make it work.

Open a JIRA issue I need to check that. This is not my favorite solution though.


Metadata have differents behaviors regarding the driver and the DB you choose, It's a bit of a pain to make it all work.

I thnik we can build an algorithm around the metadata.getUserName() when there are multiple rows returned. This is preferable to the "all type equals" version, I guess. Can you try to implements it? You'll be sure it works on Oracle ;-)

We cannot process validator before the other annotations.

Thanks for this indepth analysis, it helps a lot.

http://opensource.atlassian.com/project ... wse/ANN-61


I wasn't quite sure what you wanted me to put in this particular JIRA item. I entered http://opensource.atlassian.com/project ... wse/ANN-63 to represent the work I'm going to try to tackle. If you wanted another JIRA issue around enumtype parameters, let me know specifically what you think the bug is here, since it doesn't seem like validators are going to help here regardless.


Note mine, either, but I entered the issue regardless:
http://opensource.atlassian.com/project ... wse/ANN-62


I'll give it a go. As mentioned, I entered this as http://opensource.atlassian.com/project ... wse/ANN-63

Also, all the issues I opened defaulted to 'Major' priority. I didn't change that, but I doubt they actually classify as such. I thought you would be the best judge of that field.

Alright, I just uploaded a patch that fixes this problem for me. Specifically, it uses the metadata.getUserName() approach to find a result with that schema when there are multiple results.

http://opensource.atlassian.com/project ... wse/ANN-63

I updated this patch after reading this forum post:

http://forum.hibernate.org/viewtopic.php?t=946097

It mentions a NPE in nullSafeSet, which had a trivial fix. It wasn't related to my particular bug, but since I was in that code anyway, I thought I'd include that in the patch, since I'm going to start using this code now. :)

Applied thanks