Hi,
I look after the Joda-Time project (http://joda-time.sourceforge.net). We provide a complete replacement for the poor JDK Date and Calendar classes, and are very close to v1.0. We recently had a mail to our list (see bottom) regarding Hibernate integration which I can't help with as I don't use Hibernate.

The issue occurred because we made our key class DateTime final. According to our user, and your user guide, this entails creating a custom user type. Is this correct? It further seems that this involves extra work from then on whenever the custom type is used. Is this correct?

My main question is whether there is any solution that enables DateTime to be seemlessly added and then treated as though it is a built in basic value type? If not, then is there any possibility that Joda-Time support could be added to Hibernate?

The only other solution I can think of is for our user to create a class that wraps DateTime but is Hibernate persistable. This seems a little poor though. (I don't want to make DateTime non-final which might be another solution)

One other point. DateTime implements the ReadableInstant interface in Joda-Time. Does the presence of an interface make a difference to any of the above?

Any input welcome (remembering I've not used Hibernate ;-)
Thanks
Stephen

-------------------------
User report to our list
-------------------------

Strings and Integers are handled nicely in Hibernate because support
for it has been built in from the ground up. To persist other types in
Hibernate, it is necessary to implement some extra interfaces so that
Hibernate knows how to persist and restore the type. There's another
(ugly) way to persist custom user types that can't implement
interfaces, but it entails adding extra mapping information to both
the property definition and to the query if the type is one of the
parameters in the query.

Instead of having the following accessor in my entity class and having
Hibernate determine the type from the return value as follows:

/**
* @hibernate.property
*/
DateTime getDateCompleted()
{
return mDateCompleted;
}

I would need to remember to do the following:

/**
* @hibernate.property type="com.realconnected.util.DateTimeUserType"
*/
DateTime getDateCompleted()
{
return mDateCompleted;
}

That part actually isn't bad. The more annoying part is that I would
have to specify the mapper class for the type every time I use the
type in a new query. This is problematic because the DateTime type is
used frequently in our queries.

Going with a UserType is the way this has to be done currently, nothing much you can do about this.

"default type" definitions are currently under consideration but implementation is not started yet. I don't think any "default types" for classes from other projects will be added to the Hibernate Type model as it currently is.

Is this saying that you might in the future support seamless integration of other basic types?

I understand your not wanting to add any basic types in the current system. Would it be easy for a user to add such an additional mapping themselves by editing the Hibernate source code?

Stephen

Some possiblitiy to tell Hibernate "always use this UserType for that class" might be added if it is cleanly possible.

Adding a "default" mapping yourself is quite easy if you patch the Hibernate source, just edit TypeFactory