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

[Gunnar Morling]

2018-04-10 0:07 GMT+02:00 Brian Goetz <brian.goetz at oracle.com>:

> First, let me answer the questions embedded here and ask a few more:
>
>    * Concrete records are final: that'd prevent records to be used for
>> modelling some inheritance hierarchies. While not ideal, I don't think
>> it'd
>> be too big of a problem in practice, as from what I see, oftentimes users
>> try to avoid inheritance in their persistent domain models anyways
>>
>
> There is a notion of abstract record, but no concrete-to-concrete
> inheritance.
>

Right, that's what I was referring to above: JPA allows for
concrete-to-concrete inheritance of entities. Such models couldn't use
records as per the current proposal.

>
> Does JPA rely on runtime-generated proxies?  If so, what does the proxy
> inject into the class?  (In any case, for proxies, finality is a problem.)


Yes, indeed proxies are used in some cases. E.g. when an entity is
configured to lazy-load specific properties, JPA would return a proxy for
the entity, which contains the logic to lazily fetch the property value
upon first invocation of someEntity.someLazyProp().

>
>    * Custom methods: It's not fully clear to me, whether additional methods
>> would be allowed on records or not; For JPA, that'd be desirable, as users
>> often add methods with entity-specific logic to their entities
>>
>
> Yes, there's no problem with additional methods, static or otherwise.
>
>    * Annotation semantics: I couldn't find any example of records with
>> annotations, but IIUC, something like
>>
>
> There's no problem with annotations, but it's not yet clear how we would
> map annotations on record components to desugared members.  In your example:
>
>>          @Entity record Book(@Id long id, String isbn) { ... }
>>
> would the @Id annotation go onto the field, the constructor argument, or
> the getter?


For JPA, some control would be needed to decide between field or getter
(the location of the @Id annotation determines the default access strategy
to be used by the JPA provider, and a user may wish to use one or the
other).

(Optional) propagation to constructor parameters would be interesting for
Bean Validation, which then could make use of the constraint annotations to
validate constructor invocations.


>   The only justifiable path I can envision would be to map to all of them
> that would be permitted by the @Target of the annotation, which might or
> might not work for your cases.
>

That wouldn't really work well for the JPA use case, as we'd end up with
the annotations on fields *and* getters, which is at least confusing (not
sure out of my head whether it's not even considered illegal).

One more thing I'm realizing now is that the proposal is to name generated
read accessors fieldName() instead of getFieldName(). The latter is
expected by JPA (currently at least, it might evolve of course).

So overall, as things stand, it appears to me as if it wouldn't really be
beneficial to use records as JPA entities.