Records -- Using them as JPA entities and validating them with Bean Validation

[Brian Goetz]

>
> This is the high-order bit; if we can't address this then the rest 
> don't matter.
>
>       Are there concrete criteria that we can use to reason about when
>     it would try to create a proxy?
>
>
> One criteria is whether there are lazily loaded references to 
> entities. E.g. consider this model:

Right.  In this case, then I think its fair to say that the aggregate 
doesn't meet the goals for records, which is "the state, the whole 
state, and nothing but the state."  An entity with lazily materialized 
properties really has some hidden external state, which may in fact be 
the entire database.

But, if the framework will detect that the domain class is final, and 
not attempt to lazily load anything, then this may be fine (though 
potentially limiting.)

>
> Yes, indeed Hibernate ORM will choose one of them in this case. It's 
> not a mapping a user would typically use themselves, but this 
> shouldn't matter here.

So, if the annotation were lowered onto both the field and the getter, 
then its quite possible things would "just work" -- in this case.

As you probably saw, there was some discussion that suggested that the 
best thing to do would be to create a new Target kind for records.  In 
this case, of course, frameworks would have to be updated, but then 
there would be no "guessing" about which was meant.

> For Bean Validation, things are a bit worse. The spec is very clear 
> about the fact that a constraint annotation should only be put to a 
> field *or* the corresponding getter, as otherwise both constraints 
> would be checked when validating an instance of the type hosting the 
> field and getter.

Because of the strong connection between the field and getter in this 
case, reflection will probably be able to tell you that "method x() is a 
getter for field x", which a framework could use to determine that this 
is a harmless conflict.

> Agreed. But I also think the question of custom equals()/hashCode() 
> methods is important.

The constraint on equals/hashCode is a contingent one, and it relates to 
the possible existence of ancillary fields.  We're still working out the 
details here, so we should have some more clarity once that happens.