Question on updating a record using hibernate

[Jack Tauson]

While I am updating columns of a table using Hibernate, on the user interface, I'm not making any mandatory requirement that if there are 7 fields in the table, user must update 7

So there is a chance user can end up updating 3 fields sometimes or 5 or 7 (total fields).

In the case where the user is not sending all the parameters to the controller, am I supposed to check if user has supplied all the fields and if not get that or those fields from the database and send it along with the update request so that hibernate won't insert null?

[Paul Clapham]

It seems unlikely to me that if Hibernate gave you a Customer record, and you updated the customer's credit limit but nothing else, because you wanted to leave all of the other columns unchanged, then Hibernate would set all of the other columns to null. I think you may have had something else in mind when you said "insert null" but I can't quite tell what it was.

[Jack Tauson]

Paul Clapham wrote:It seems unlikely to me that if Hibernate gave you a Customer record, and you updated the customer's credit limit but nothing else, because you wanted to leave all of the other columns unchanged, then Hibernate would set all of the other columns to null. I think you may have had something else in mind when you said "insert null" but I can't quite tell what it was.

I meant the same thing when I said "insert null" in mind. Asking because I don't see any example online (unless I'm missing something) which shows these checks. Do you mind sharing some online resources talking about this with some examples?  

[Paul Clapham]

Seems to me you just need an example of updating a record. Like I said I would be astonished if there was a requirement to update all fields. I'm just giving you that answer instead of "hell no" because I haven't used Hibernate for a long time.  Or write your own test code and see what happens.

[Liutauras Vilda]

@OP

Depending how you have your implementation currently, but, consider if this approach makes sense to you.

Technically, what you describing is a patching, where some or all fields get updated.

So what you can do, is:
1. Get an existing object from db
2. Have a mapper DTO -> Model and vice versa
3. Now just use a mapper accordingly to map fields that aren't null/empty (whatever denotes not updated) in DTO and update Model fields
4. Persist an updated object

There is slightly another approach if you following Open API specs, but let's not dive into that yet.

[Tim Holloway]

When you are using an ORM persistence system such as Hibernate/JPA, you fetch and store ALL of the column data in a single operation. You don't code column-by-column operations. Instead, you fetch the row as an Entity instance, update the properties of that row that you want to change, then save the instance back to the database.

ORMs are smart and they know what columns you actually altered, so they will internally code efficient SQL to handle that.

[Himai Minh]

Jack,
You may find a Spring Boot's @PatchMapping example from this public educational Github sample code:
https://github.com/springframeworkguru/spring-6-rest-mvc/blob/77-flyway-intit-script/src/main/java/guru/springframework/spring6restmvc/services/BeerServiceJPA.java

[Jack Tauson]

Thanks All. I'm using Hibernate Mapping  XML file stuff which is quite old and doesn't use any annotations so what I ended up doing is if a user selects something from the drop-down in the user interface, I am getting the data from the database table based on the user selection for that particular row using the primary key and populating it on the form fields. That satisfies the user as well as they see what they are going to modify and serves the purpose of not sending null from the user interface.

[Tim Holloway]

I recommend that you budget some resources towards modernization before that breaks. Software does NOT "live forever", despite what Management thinks. It rots primarily from the outside in as hardware, operating systems, and ultimately language environments and support libraries change around it. Those changes not only add up, they snowball. It's known as "technical debt" and just because it's not the kind of debt that a Bean Counter can put on a spreadsheet doesn't mean it's not very, very expensive.

The fact that you're using XML files makes me fairly certain that you are using Legacy Hibernate. Hibernate is presently available in 2 forms: legacy form, and Java Persistence Architecture (JPA) form. Someday the legacy form is no longer going to be supported and even now, the number of experts in it is fairly low.

JPA, on the other hand, is part of the JEE EJB3 specification and you can expect much better support over a longer period. It is relatively easy to convert from legacy Hibernate to JPA Hibernate, but the sooner done, the easier/cheaper it will be. JPA, incidentally, was shaped in large part by people from the Hibernate team, which is one reason why it's fairly simple to convert.

Incidentally, the XML files still work, although you will probably see differences between the Legacy and JPA Hibernate XML formats. It's better to use annotations, though, as it reduces the number and complexity of XML files. The XML is then used to override the annotations when special needs arise.

[Jack Tauson]

Tim Holloway wrote:I recommend that you budget some resources towards modernization before that breaks. Software does NOT "live forever", despite what Management thinks. It rots primarily from the outside in as hardware, operating systems, and ultimately language environments and support libraries change around it. Those changes not only add up, they snowball. It's known as "technical debt" and just because it's not the kind of debt that a Bean Counter can put on a spreadsheet doesn't mean it's not very, very expensive.

The fact that you're using XML files makes me fairly certain that you are using Legacy Hibernate. Hibernate is presently available in 2 forms: legacy form, and Java Persistence Architecture (JPA) form. Someday the legacy form is no longer going to be supported and even now, the number of experts in it is fairly low.

JPA, on the other hand, is part of the JEE EJB3 specification and you can expect much better support over a longer period. It is relatively easy to convert from legacy Hibernate to JPA Hibernate, but the sooner done, the easier/cheaper it will be. JPA, incidentally, was shaped in large part by people from the Hibernate team, which is one reason why it's fairly simple to convert.

Incidentally, the XML files still work, although you will probably see differences between the Legacy and JPA Hibernate XML formats. It's better to use annotations, though, as it reduces the number and complexity of XML files. The XML is then used to override the annotations when special needs arise.

Yeah, I completely agree and would definitely want to move towards JPA direction rather than using Legacy Hibernate.