• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Question on updating a record using hibernate

 
Ranch Hand
Posts: 423
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Marshal
Posts: 28263
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 423
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Marshal
Posts: 28263
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Marshal
Posts: 8880
638
Mac OS X VI Editor BSD Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@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.
 
Saloon Keeper
Posts: 27886
198
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Bartender
Posts: 2436
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 423
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 27886
198
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 423
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic