[hibernate-dev] Hibernate O/RM Java 8 API.

[Steve Ebersole]

Let's keep this on list ok?  Thanks.

First, have you seen the new hibernate-java8 module that is part of 5.0?

Some replies in-line...

> But I am curious what would be your opinion on this extended API idea and
approach that I took and whether you would for instance consider taking it
under the hibernate umbrella as a kind of official extension in future.

Hard to say.  More than likely the next major release will drop support for
Java 6.  I personally see no benefit in supporting "just" 7, so I'd likely
go right to 8.


>
> At the moment I would like to focus on three things:
> - Introduce typed (generic) queries, because at this moment streams of
Object's are not quite useful.

Yes, we should certainly do this.  I just made some Session methods
generic, so this certainly fits.   But this is not Java 8 specific in any
way...

>
>
>
> - Enable registration of LocaleDate, LocalTime as query params.

You can do that now:
* org.hibernate.Query#setParameter(java.lang.String, java.lang.Object)
* org.hibernate.Query#setParameter(java.lang.String, java.lang.Object,
org.hibernate.type.Type)

I assume you mean adding method signatures accepting those specific types?


>
> - Custom type handlers for LocalDate, LocalTime
>
> - Custom type handlers for Optional<?>

No idea what you mean here.  What do you mean by "type handler"?

And as far as using LocalDate, etc as query parameters... you can do that
now.  Do you mean specific methods accepting them?


>
> If you could help me with one thing on the regarding the Optional
attributes mapping. As my understanding is correct the relation/entity
mapping are being handled by OneToOneType, ManyToOneType classes. To your
knowledge would it be possible to provide an overrided version of them, or
it would rather require to alter them directly in Hibernate core?

As I understand it (I have not looked overly deeply yet), we would
essentially need a Type representing Optional that wraps an "underlying
Type".  It is very similar to the idea of AttributeConverters.  We could
handle it at a lower lecvel here too like we do for AttributeConverter.