This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
What is this, a job interview question? Or an assignment? We have reasons why we don't like answering these out right. So, what do you think?
Up front I will tell you that Hibernate does this for you so you have to think of why you would want change this behaviour and you will probably have your answer. Also what I would suggest is you think of the data you are mapping; it will already have identity in a different context. Does it make sense to change that?
that's the response what i thought my subject would attract .... a possible interview question. I am sorry for that as i typed the question in a hurry.
Well honestly it is not. I was going through this official hibernate Tutorial which said
There is one caveat: Never use the database identifier to implement equality, use a business key, a combination of unique, usually immutable, attributes. The database identifier will change if a transient object is made persistent.
Generally, i use a tool that reverse engineers from a database table to create corresponding hibernate classes. That tool simply uses the table primary key and maps it to the <id> element.
Does database identifier mean "primary key"?
If yes then how does the database identifier change if i am not modifying it?
What am i missing here?
I know it might be a silly question but i would appreciate any help.
I think the issue is more related to transient objects. A transient object will have a null or 0 for its identifier. A persistent or detached object will have the identifier set. If you are comparing a transient object to a persistent/detached object and are using the primary key (database identifier) in the equals method, then they will not be equal, even though they have the same data.