Re: [hibernate-dev] Hibernate O/RM Java 8 API.
2015-05-19 18:16 GMT+02:00 Steve Ebersole <steve(a)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