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 acce
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
> 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 i
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 6.0
+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 Object type *unless* the
+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 to-date
+1
I remember that Spring Data CRUDRepository has this restriction that ID
extends Serializable just because Hibernate required it so. I agree that we
should drop this restriction and allow non-Serializable @Id as other JPA
providers.
On Mon, Mar 27, 2017 at 9:54 PM, Christian Beikov <
christian.
