Hi everybody,
I have the following situation and would appreciate any help/suggestion on how to deal with.
There is a Java application using Hibernate 5.2.11. The application exposes a REST services to a web client. It has a domain model represented by persistent entities(managed in Hibernate Session fashion). Each web client view needs only a sub-graph of a certain persistent entity graph(partial marshalling is implemented in the REST controller using @JsonView). Once an entity sub-graph gets modified on the client side I need to persist the changes. In server-side terms: once such object is unmarshalled(implicitly by Jackson unmarshaller) I'm using the Session.merge() operation to change the current persistent instance. However I can not figure out a consistent way for the application to differentiate on merge:
- if a property was not serialized when the object sub-graph was retrieved by the client
- if a property was set to null on purpose during client side editing

Maybe you have other approaches for this problem.

Thanks in advance

Check out the hibernate-types project if you want to map JSON columns.

Thanks for the reply, informative.
However I don't have any JSON column in the database. What I'm doing is:
- loading persistent entities from the database
- partially serialize(sub-graph) the persistent entities as JSON and send them to a web client across a REST layer
- the client may edit some of the entity properties and issue an update operation
- back on the server side the entity is deserialized from JSON to a Java type. Then it is merged on the corresponding persistent entity from the database. And here is the problem: how to tell if a property was modified by the client(set to null) or it was not serialized(hence null) when the client requested it?

Thanks in advance

Just use merge, and Hibernate will automatically detect any changes done by your client.

This is what I'm currently doing. But let's take an example to better illustrate the issue.
Let's say I have the entity class Customer with phoneNumber property. I don't need this property so I do not serialize it. The web client edits this entity and sends it back to server side. Unmarshalling the JSON it will result in a detached instance of Customer with phoneNumber = null (because it was not serialized and sent to the client). Now when I merge this Customer instance I'll overwrite phoneNumber with null without intending to do it. How to avoid this?

It's simple.

You need to create a business specific DTO for each use case so that you know what do you fetch from you entity and what to merge back.

So, once you get the DTO from the client, you will fetch the entity from the database and only call:

Thank you for the reply.
I agree with you this is the programatic approach. For every REST operation I know what properties set(object sub-graph) gets sent to the client and what to merge when they get back.
- however we have a large number of REST operations(and sub-graph configurations). It would become error prone if somebody forgot to set a property during the programatic DTO to entity transformation.
- also this DTO-entity progrmatic mapping generates a considerable amount of boiler plate code; maybe is a good candidate for automation

Since is a horizontal concern, I was wondering if there is a way to automate, not having to do this DTO-entity transformation programatically ?

I was thinking about:
- customizing the Jackson serialization so that for not fetched entity properties to serialize some java Proxy object.
- when trying to merge back the object to create a custom implementation of DefaultMergeEventListener that avoids to copy values that refer to this special Proxy palceholder
But this looks complicated, requires some effort, depends on Hibernate internal API that might change... Is there an easier, less invasive way to automate this(dirty check of persistent entities serialized over the network to another tier)?

There's another approach which is even simpler.

As I explained in this article, you can map multiple subentities to the same table.

This way, you won't use just one entity, but multiple ones, each one mapping just as many columns that it needs for that business use case.

What you are looking for are Blaze-Persistence Entity Views which have been designed as efficent DTO mapping library for a JPA backend. Instead of using JsonView you would define interfaces with abstract getters that map on attributes or even JPQL expressions if you like.
The other way back, from DTO/Entity View to the JPA Entity obviously only works if you only reference attributes. I don't have a full solution that offers everything out of the box for the REST case yet, but I'm trying to get there. Detecting whether an attribute wasn't set or was set to "null" could be done with sentinel values for the "uninitialized" case.