Re: [hibernate-dev] 6.0 - id type

+1 for that. Stumbled over that once or twice in the past and wondered what the reasons were. Mit freundlichen Grüßen, *Christian Beikov* Am 27.03.2017 um 19:37 schrieb Steve Ebersole: > In all versions of Hibernate

Re: [hibernate-dev] 6.0 - id type

+1 for removing the Serializable restriction On 27 March 2017 at 18:37, Steve Ebersole wrote: > In all versions of Hibernate to-date we have required that the Java type of > an id be Serializable. Strictly speaking JPA has no such restriction - it > says ids can be any

[hibernate-dev] 6.0 - id type

In all versions of Hibernate to-date we have required that the Java type of an id be Serializable. Strictly speaking JPA has no such restriction - it says ids can be any Object type *unless* the entity is to be serialized, in which case the id must be Serializable (duh). As we transition into

Re: [hibernate-dev] [SEARCH] 6.0: what if we flipped our metadata definition upside down?

> Independently from which one we read from first, won't there always be > a risk of forgetting the other input processing blocks? With that in mind: yes, even if what I propose, there will still be a risk of forgetting to add a feature to one API or the other, but I think the risk will be lower

Re: [hibernate-dev] [SEARCH] 6.0: what if we flipped our metadata definition upside down?

I don't mean this to be a strict "No", but I'm not convinced for now on the benefits such an exercise in refactoring brings.. In a nutshell the goal is reading from {Annotations, ProgrammaticAPI} -> Actual applied Metadata. Independently from which one we read from first, won't there always be a

[hibernate-dev] [SEARCH] 6.0: what if we flipped our metadata definition upside down?

Hello, Currently, the medata definition mechanisms in Search work this way: - the primary way to define metadata is using annotations - the secondary way to define metadata is programmatic, *but it only instantiates annotations,* simulating annotated entities - classes needing to