-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 9 posts ] 
Author Message
 Post subject: How to dirty check an entity that might get modified?
PostPosted: Thu Nov 09, 2017 6:02 am 
Newbie

Joined: Tue Sep 13, 2016 11:24 am
Posts: 15
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


Top
 Profile  
 
 Post subject: Re: dirty check for persistent entities partially JSONserialized
PostPosted: Thu Nov 09, 2017 7:50 am 
Hibernate Team
Hibernate Team

Joined: Thu Sep 11, 2014 2:50 am
Posts: 1628
Location: Romania
Check out the hibernate-types project if you want to map JSON columns.


Top
 Profile  
 
 Post subject: Re: dirty check for persistent entities partially JSONserialized
PostPosted: Thu Nov 09, 2017 10:59 am 
Newbie

Joined: Tue Sep 13, 2016 11:24 am
Posts: 15
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


Top
 Profile  
 
 Post subject: Re: dirty check for persistent entities partially JSONserialized
PostPosted: Thu Nov 09, 2017 11:26 am 
Hibernate Team
Hibernate Team

Joined: Thu Sep 11, 2014 2:50 am
Posts: 1628
Location: Romania
Quote:
- 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?


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


Top
 Profile  
 
 Post subject: Re: How to dirty check an entity that might got modified?
PostPosted: Thu Nov 09, 2017 11:34 am 
Newbie

Joined: Tue Sep 13, 2016 11:24 am
Posts: 15
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?


Top
 Profile  
 
 Post subject: Re: How to dirty check an entity that might get modified?
PostPosted: Thu Nov 09, 2017 1:44 pm 
Hibernate Team
Hibernate Team

Joined: Thu Sep 11, 2014 2:50 am
Posts: 1628
Location: Romania
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:

Code:
Customer customer = entityManager.find(Customer.class, customerPhoneDTO.getId())
customer.setPhoneNumber(customerPhoneDTO.getPhoneNumber());


Top
 Profile  
 
 Post subject: Re: How to dirty check an entity that might get modified?
PostPosted: Thu Nov 09, 2017 3:17 pm 
Newbie

Joined: Tue Sep 13, 2016 11:24 am
Posts: 15
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)?


Top
 Profile  
 
 Post subject: Re: How to dirty check an entity that might get modified?
PostPosted: Thu Nov 09, 2017 3:32 pm 
Hibernate Team
Hibernate Team

Joined: Thu Sep 11, 2014 2:50 am
Posts: 1628
Location: Romania
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.


Top
 Profile  
 
 Post subject: Re: How to dirty check an entity that might get modified?
PostPosted: Wed Nov 22, 2017 6:37 am 
Beginner
Beginner

Joined: Sat May 21, 2011 7:40 am
Posts: 22
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 9 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.