The .load method is useful in situations where you "know" the record exists, and you don't want to have to test the return value each and every time you read in an object from the database. You are asserting that the object does indeed exist in the database when you call the method.
Think of an application that assigns a user ID to a user account whenever it is created. The user account would probably have an associated username candidate key, but the real primary key for the record would be the sequence-assigned user ID. That would likely be the value passed around the application from screen to screen (in a web app, for example).
Now, since the user ID was assigned by your system, then you can assume that all user IDs you load from the database are indeed associated with a user account that exists in the database. In this case, use .load. You can write code such as:
Code:
User user = session.load(User.class, userID);
user.setName(newName);
You don't have to worry about getting a NullPointerException, since the load method's contract is to throw an exception on failure to locate the record. Likewise, you don't have to do any sort of if (user == null) throw ... test, since Hibernate does it for you.
Now, on the other hand, if you had an app that you let the end user enter user IDs in a form field, then you
would want to have Hibernate return a null value rather than an exception. This is because it is a normal--rather than abnormal--scenario for your app to receive a user ID for a user that does not exist.
I hope that (my philosophy on) this helps.
Login
FAQ
Search
