Re: [hibernate-dev] 5.2 or 6.0
For what it is worth, the specific changes I have in mind are to scope the
following delegates to our JPA javax.persistence.metamodel.Metamodel impl,
and to expose them via our extension contracts:
1.
org.hibernate.type.proposed.spi.descriptor.java.JavaTypeDescriptorRegistry
2.
org.hibernate.type.proposed.spi.descriptor.sql.SqlTypeDescriptorRegistry
3. org.hibernate.type.proposed.spi.basic.BasicTypeFactory - which is a
redesign of the current org.hibernate.type.BasicTypeRegistry based on
idea of "composing"a BasicType from JavaTypeDescriptor,
SqlTypeDescriptor and AttributeConverter
(1) and (2) are exposed by a new
org.hibernate.type.proposed.spi.descriptor.TypeDescriptorRegistryAccess
interface that org.hibernate.Metamodel extends (along with
javax.persistence.metamodel.Metamodel).
For 5.2 I'd also likely not do (3), instead just moving BasicTypeRegistry
there and refactoring BasicTypeRegistry -> BasicTypeFactory in 6.0
On Wed, Jun 8, 2016 at 4:57 AM Emmanuel Bernard <emmanuel(a)hibernate.org>
wrote:
Does the HQL to native query mechanic use this too?
> On 08 Jun 2016, at 08:50, Gunnar Morling <gunnar(a)hibernate.org> wrote:
>
> JavaTypeDescriptorRegistry is used by Hibernate OGM in
> (o.h.o.type.impl.TypeTranslatorImpl).
>
>> From my side, the proposed change is good, esp. if it fixes some
existing
> bugs. It'd lock down OGM to a specific minor of ORM, but that'll happen
> anyways once we make use of the changes around schema tooling done in ORM
> 5.1.
>
> --Gunnar
>
>
> 2016-06-07 19:49 GMT+02:00 Steve Ebersole <steve(a)hibernate.org>:
>
>> Currently we are still working on 6.0 "on top" of 5.2, meaning that
all
of
>> the changes we are proposing to ORM for 6.0 are kept in a separate
>> repo/project using ORM 5.2 as a dependency.
>>
>> As I work on 6.0 I have come across a change that I would like to make
that
>> requires that I change something in ORM proper. The specific change is
>> that I would like to remove static access
>> to org.hibernate.type.descriptor.sql.SqlTypeDescriptorRegistry
>> and org.hibernate.type.descriptor.java.JavaTypeDescriptorRegistry and
have
>> these scoped as part of the SessionFactory instead (technically as part
of
>> the org.hibernate.metamodel.internal.MetamodelImpl associated with a
>> SessionFactory).
>>
>> There are 2 ways I can go about this:
>>
>> 1. branch 5.2 and start 6.0 dev on master
>> 2. make this change in master for inclusion in both 5.2 and 6.0
>>
>> (2) is certainly the more convenient approach. But even beyond
convenient,
>> I have seen some bugs from the fact that these are statically typed -
>> theoretically they should be scoped to the SF since the SF can mutate
them.
>>
>> However making that change in 5.2 has some risks depending upon whether
>> apps/integrations use it. Anyone aware of any integration(s) accessing
>> these 2 registries?
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev