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

[Jakub Narloch]

2015-05-19 18:16 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> Let's keep this on list ok?  Thanks.
>
> First, have you seen the new hibernate-java8 module that is part of 5.0?
>
Ahh, I somehow miss that, going to take a look right away.

>
> >
> > 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?
>
Yes, I meant a convinient methods similar to those setDate and setTime,
something like setLocalDate, setLocalTime

>
> >
> > - Custom type handlers for LocalDate, LocalTime
> >
> > - Custom type handlers for Optional<?>
>
Sorry for ambiguity. I was refering to "custom user types" from the
reference, this is at least my understanding how Hibernate maps the Object
to SQL in general.
To sum up what I would like to be able to do "mapping" of an entity as
fallows:

class Employee {

  Optional<Employee> manager;

  LocalDate createDate;
  LocalDate updateDate;
}

So some extra org.hibernate.type.Type definitions will be needed similar to
those that you had defined in hibernate-java8.

>
>
> >
> > 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.
>
Cool, I will explore this a bit more and see what I could do with that.

Thanks,
Jakub