Open derekm opened 4 weeks ago
@derekm why not using an adapter or (de)serializer? works smoothly and avoids to do this kind of API which will quickly require @JsonbSerializeAsMultipleFields({"id", "date"})
for example, and later another model cause one field needs a specific serialization and ultimately requires deduplication only to use jsonpointers?
@rmannibucau -- Even if JPA Entities could produce the same structure as their respective value-objects that transform join-reference columns back into object IDs, then I think maybe you can't avoid defining and distributing your value-objects anyway as client interfaces, since you don't really want the fat Person field on the client objects (unless we get a marriage between JPA and JAX-RS for graphql-like object-graph retrieval via MicroProfile Rest Client-like web clients).
@derekm if ambiguous I agree, you often (90+%?) cut the relationship at their id + common fields, my point was just that this kind of API becomes quickly greedy whereas it is already doable to solve that issue with at least 2 (3) annotations, agree they require code but it is likely not that bad IMHO.
Jackson has added
@JsonManagedReference
,@JsonBackReference
, &@JsonIdentityInfo
to support putting JPA Entities directly to the wire.Similar annotations in JSON-B would be useful for getting rid of entity-object-to-value-object and value-object-to-entity-object transformers as an unnecessary layer of code.
What I think I'd like is something akin to
@JsonbSerializeAsSingleField("person.personId")
, as in:But I suspect what I want is slightly more involved than this, and might require JSON deserialization to know more about JPA entities and entity manager, since IDs should become managed references on deserialization.