whaot? i'm telling you how you map enums (by a customizable customtype) and if you dont want to write it your self you go look in the annotations and ejb3 project on how that is done.

I also explain why we can't rely on jdk5 features in the core because noone have showed or made something that allows us to be compatible which is extremely important.

What is the difference between *true* jdk5 support and you writing:

<property name="anEnum">
<type="org.hibernate.type.EnumType">
<param name="enumclass">YourEnumClass</param>
</type>
</property>

?!

as far as I know the enumtype can even be intelligent dependent on the underlying resultset.

And the UserType system have been here since hibernate were born (almost) so you can trust me when i say it will be around a long time yet ;)

As I stated before, again with deference, we would like support for enums without having to write custom types.

I'm not trying to degrade the conversation here, but you're repeating what Michael said back in August.

This thread was picked up again because someone had hoped (as did I) that this was included in 3.1. Which it has not been.

I wanted to make sure a core issue of the thread (being that we would like support for enums without having to write custom types) is re-iterated.

I apologize if you took offense to my reply.



If that's all it takes, hoorah. But as I understand org.hibernate.type.EnumType, that's not all that has to be done. I may be completely mistaken, which happens often. I'll review and try to get it to work new school vanilla style.



Noted. As I hope you note the nature of my post above.

Use Hibernate Annotations for native support

...and that mapping code I have shown have been available out of the box for months and have *always* been possible. We just dont put jdk 1.5 deps into Hibernate3 core, only annotations and HEM

What would be helpfull is to allow a usertype to be registered against an interface or a base class. That way you woudl not have to declare the user type in each property explicitly. (just like hibernate does internally when it registers the native type handlers).

Additionally if the type could be given the reflected type of the property to further customize itself then you could create very robust handlers.

For example the EnumUserType could be registered against the base Enum type. Then when it gets constructed by the Configuration object it would be given the class of the spefic Enum. Now you have only to make one little registration once, and all enums are supported.

I currently have something like this implemented as a post process on the configuration that "upgrades" types to my registered type list (as hibernate exposes no way to register new types to its stock class->type mapping system). Its just that my solution to the problem is fragile as i have to understand about all the different types and how to iterate thourhg thier inner properties (ie Components, Entities etc).

if you can do that without breaking compatibility and seperation of concerns then please do...but please take a good look at <typedef> since it allows you to package this up so you just need to specify the typename.

Yes; it wont be able to use reflection for validating it but it will definitly work.

The problem i have with using typedef is it still requires me to explicitly specify the type on the definition of the property. Which is the main thing im trying to avoid.

This become especially usefully when combined with Hibernate Annotations, where there are sensable defaults for most types of mappings, so you document less.


What type of impact / would it be possible to extend the <typedef> definition so that it had an optional heuristic type. That way when the binder is runnign the heuristics code to determine an appropriate type it could also check all <typedef>s with defined heuristics. The type of a property could still be explicitly set and would not be impacted by the additional heuristics registered.

As an addon, the reflected type of the property could be auto-added as a parameter to the typedef. Combine that with the ability to match based on inheritance and you have what i had to implement manually.



This would signify that the type should be heuristically matched against all decendants of java.lang.Enum.

create a patch and put it in jira...but I don't think its likely to be added to the core ...too much implied magic.

and how many enums do you actually have that makes it a problem to add type="ColorEnum" to the properties that needs it ?

also remember that types are normally viewed as immutable...

Currently we have around 20 different enums used in 200 or so classes.
Thats a lot of rote mapping work.
We also have 15 or so custom datatypes that are used throughout, which again need custom mappings. Hence why i wrote the code i wrote. It simplifies 90% of the mappings to just "this properties is or isnt persistent". The rest is handled by "teaching" hibernate how to handle new datatypes.

Its applicable for more than just enums. Its applicable to any custom types you need to use w/o the hassle of havign to know that there is a custom Type defined for it.

I am currently working with 8 modular projects (soon to be expanded) and its cumbersome to have to explicity define the Type for all the custom types. The ability to register it and use it (unless explicitly overriden) provides a more robust configuration. If its appropriate for native/stock types, I dont see why it wouldnt be for custom ones as well.


The types created would be immutable, it would be comparable to


but you wouldnt not have to explicitly define it everywhere you used it. Thus simplifying the configuration.

Even a hook to allow an interceptor for the resolution of typeName/params to types would work. It would them remove the code that i have that needs to walk the Mappings and "upgrade" the datatypes.

Stop. You can use a <typedef> for each enum you have. It uses a single smart UserType that can persist enums (one for JDK 5.0 with auto-guessing is available in Hibernate Annotations). You then reference that new type by name in your property mappings. End of story. There is nothing to improve here.

I think what he is trying to accomplish is to provide a hook in hibernate that can allow him to just write:

<property name="value"/>

and let the mechanism detect this.

I think it could at least be worth considering a contribution that we may or may not adapt when we will go over some of the other issues we have with typedef.

to cmrudd - using interceptor is not possible here since the Interceptor is not active at configuration building time.

Such a mechanism would be completely unrelated to enums, its the "change the default mapping type" feature that has been discussed for ages. Someone provide a patch to JIRA.

yes christian but it is actually also a very nice solution for specifying enums as the user stated ;)

so cmrudd put a patch in jira.

Exaclty max, I'm just using enums as the example as its the simplest and one lots of people can relate to.

By "interceptor" i didnt mean the existing interceptor, i mean the concept of an interceptor. Ie



A type resolver that can be registered with the configuration such that its consulted just before delegating to the TypeFactory.heuristicType method.

Ok. Ill do up a patch(s). A simple one using the TypeResolver concept. And a more complex one exapnding on my concept of adding extra data definition to the TypeDef constructs.