Records -- Using them as JPA entities and validating them with Bean Validation
brian.goetz at oracle.com
Tue Apr 10 15:13:09 UTC 2018
> 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().
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? What if the domain class is final?
> 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).
Its pretty important that there be no control knobs. (The first is the
most dangerous; once you have one, you will soon have many.)
> 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
I have to assume that if a framework sees it on both, it will (or can)
make a choice about which it finds preferable?
> 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).
Surely this could evolve.
> So overall, as things stand, it appears to me as if it wouldn't really
> be beneficial to use records as JPA entities.
I think the finality is the real question here -- so let's discuss that.
More information about the amber-dev