• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Business key in hibernate

 
neil johnson
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A business key is a property, or some combination of properties, that is unique for each instance with the same database identity.

I am confused with "the same database identity" .

excluding this "the same database identity" , i understood that business key is different for each instance.

can any one give me an example of what the definition means.
 
maitrayi vasishtha
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Business Key identifies the instance in JVM uniquely and it need not be stored in a db.
DB key is always the part of the db table.

Two beans can have same DB key but not same business key.



 
Christian Dillinger
Ranch Hand
Posts: 200
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
maitrayi vasishtha wrote:Business Key identifies the instance in JVM uniquely and it need not be stored in a db.
DB key is always the part of the db table.

Two beans can have same DB key but not same business key.


That's wrong... A business key is a property or set of properties which identifies the record "as the user does". The customer "John Doe from SomeLittleTown House No. 4" is unique. The combination of "John", "Doe", "House No. 4" and "SomeLittleTown" is the business key. Of course these information are persisted. The user is not interested in knowing that this customer has the surrogate key 123456. Maybe he is interested that the customerId is 123762 (which might be another business key!) There is no need to have a unique index that forms the business key.
And you can change values that form a business key. But you should never ever change the value of a surrogate key. (You can do that with Hibernate using either native queries or some kind of hql. But not by modifying the properties.)

Of course two beans can have the same business key inside a VM. As long as you can detect that they are equal "as the user defines equality" everything is fine.
 
maitrayi vasishtha
Greenhorn
Posts: 9
 
Christian Dillinger
Ranch Hand
Posts: 200
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


If thats an answer to my post your are misunderstanding the posted link. OUTSIDE a session the business key CAN be used to identify instances uniquely IF AND ONLY IF you override equals and hashCode. THEN a set can detect that both both instance are about the same database row.
Try it, do not implement equals and hashCode. Load the same row via two different sessions and put them into a Set. There will be two entries because equals and hashCode default to Object#hashCode and Object#equals.
 
neil johnson
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
maitrayi vasishtha wrote:
Two beans can have same DB key but not same business key.


i have one doubt regarding above statement. If two beans have same DB key - that means both are representing the same row

How is it possible to have same DB but different business key?

For example there is record with values : username - johny , password - sadfafadf , firstName - john, lastName - neil and DB key of 1234 (assume business key is usename)

In session1 a instance obj1 holds the record and in session2 another instance obj2 holds the record and modified the username value.

Now if i am attempting to store both the instances into a SET , what would be the situation. Here both instances have same DB key but different bussiness keys. since we use business keys in equals method both the instances are different. If this is the case then does hibernate creates another record in the table. If so which instance will become a new record in the database.

What ever i raised above are doubts in my mind. Kindly resovle each of questions.

 
Adam Hardy
Ranch Hand
Posts: 567
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shame no-one answered this because I was looking for confirmation of what I was thinking on this exact scenario.

I think it will depend on how you updated the entity, whether it was attached or detached, also how you have set up caching.

However I think this would be a rare case. The business key examples given as examples above include addresses which is not a true business key. If you have any list of contacts that is more than a few items long, then you would be unlikely to use address details as part of the business key. People change their addresses all the time. In an ideal world, business key values would never need updating and if for any reason in your business domain they did need updating, you would need to design for that and not rely on Hibernate to sort out potential problems like that. And I think it's reasonable to assume that your persistence engine e.g. Hibernate would act unpredictably. I'm going to google more and if I don't edit this later, then assume I didn't find otherwise.

4 years late but better late than never....
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic