Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Updating an object in Hibernate without loading entire object

 
Bai Shen
Ranch Hand
Posts: 323
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have several queries that pull two or three fields from an object in the database. Up until now, they've all been read only. But now I need to modify one of those fields. I've tried changing the object in the array, but that doesn't save to the database when I call commit.

Is there a way to do this without loading the entire object?
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Via HQL, though be careful this will sidestep any optimistic locking you've got configured unless you manually check.

What is the problem you perceive by loading the object first?
 
Bai Shen
Ranch Hand
Posts: 323
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Sturrock wrote:Via HQL, though be careful this will sidestep any optimistic locking you've got configured unless you manually check.


I don't think that I'll run into any locking issues, but I'll keep that in mind.

What is the problem you perceive by loading the object first?


I only need to know the value of two of the objects fields. And I only need to modify one. So I was looking to avoid loading all of the data from the database when all I need are just three fields.
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I don't think that I'll run into any locking issues, but I'll keep that in mind.

OK. I only mention it because you will have to manually implement optimistic locking in your query, you no longer get it for free.

I'll reiterate this point though: do you actually have an issue here? In database terms it is very unlikely to make any difference loading the entire row or a couple of fields from the row. The performance bottleneck in databases tends to be table scans, which will happen regardless. And databases don't access data on a per field basis, they use difference data blocks depending on their implementation. You could very well be performing exactly the same operation from the database's point of view if you load a couple of columns or the whole row.

In application terms, unless your object is massive its unlikely to make any difference. The data drawn over the network may make a difference, my guess though is this would be negligible and I wouldn't do anything different unless I saw an issue.

Departing from the normal way of accessing data via Hibernate introduces a raft of issue though. You push the onus onto the developers to correctly implement some of the logic Hibernate gives you for free. You side step Hibernate's own caching, so you may make performance worse. And you make maintenance harder confusing the data access logic.

It's your choice how you do this, but I'd think about these things before deciding to perform an early optimisation.
 
Bai Shen
Ranch Hand
Posts: 323
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Sturrock wrote:I'll reiterate this point though: do you actually have an issue here? In database terms it is very unlikely to make any difference loading the entire row or a couple of fields from the row. The performance bottleneck in databases tends to be table scans, which will happen regardless. And databases don't access data on a per field basis, they use difference data blocks depending on their implementation. You could very well be performing exactly the same operation from the database's point of view if you load a couple of columns or the whole row.


Do you know of any studies proving this? I was under the impression that it was faster to pull only the needed fields than the whole row.
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A common misconception. It's fairly easy to prove: run a query in whatever query analysis tool you prefer and watch the explain plan. Try a version with "select *" and a version that selects just the columns you need.
 
Bai Shen
Ranch Hand
Posts: 323
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Sturrock wrote:A common misconception. It's fairly easy to prove: run a query in whatever query analysis tool you prefer and watch the explain plan. Try a version with "select *" and a version that selects just the columns you need.


In the brief testing I did, it seems like the selecting specific fields is faster, but not hugely so. I think it really only matters if you're selecting large rows of data.
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, the explain plans are different on your database based on defining fields. Very unusual. Just out of curiosity, which database are you using?
 
Bai Shen
Ranch Hand
Posts: 323
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Sturrock wrote:So, the explain plans are different on your database based on defining fields. Very unusual. Just out of curiosity, which database are you using?


Explain plans? I'm using Postgres 8.4

I didn't use a where clause. And for the dozen or so records in the table, I was getting 15-31ms returns from "select *" and 7-15ms returns from selected fields. I used the pgAdmin tool to run the queries.
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry - whatever Postgres has equivalent to explain plans. I'm curious because I would be very surprised if the database did anything different for one query over the other - like I say, most database (that I know) don't.
 
Bai Shen
Ranch Hand
Posts: 323
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Sturrock wrote:Sorry - whatever Postgres has equivalent to explain plans.


Ah, okay. Had to google that.

I'm curious because I would be very surprised if the database did anything different for one query over the other - like I say, most database (that I know) don't.


I dunno. I'm running just a standard install. Nothing fancy.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic