OK. You are going to have to be a little less terse in your descriptions; I could paraphrase what you have written so far as "I am using something, and it is not working", which doesn't really leave much of an opertunity for anyone who may want to help doing more than guessing wildely at what could be wrong.
Can you expand (snippets from mapping file(s)? Code snippets?)?
Thats better - it makes sense now. Well, you are doing two things: first, you are creating a new POJO (your Currency object) rather than recovering an existing one from the Session. If you expect to be updating a record, you should always be getting the existing record first. Second, you are updating both values of your composite key. Composite keys are problematic in Hibernate (and in relational databases in general to be honest) so what is probably happening is since there is no object in session with that ID Hibernate is creating a new one. So its an insert which is happening, rather than an update. Of course this rather presumes your table is defined with no primary key, otherwise the DB would return an error. How does your CURRENCY table define its constraints?
I am giving the values to composite keys which are in database
When Hibernate encounters a composite key it can use a number of things to uniquely identify the object. If you have not defined a composite identifier class for your currency object, then Hibernate is using the currency object itself to uniquely identify currency objects. i.e. the class is its own PK. So when Hibernate goes to persist an object it will compare the currency class with existing records. If you have not overridden the equals method then it does this as described in the JDK JavaDocs for Object.equals(Object o). If it doesn't find one which matches, then its an INSERT you are performing in the DB not an UPDATE.
If you are letting a Currency object be its own PK, then for an update to happen, all values of the currency object must be the same as an existing one. So changing the currency text value means you will be identifying a different record. So its pointless to do this unless you override the equals method for Currency (and the hashCode method).
Of course, this can only happen if your composite key is not actually defined in the DB, otherwise the DB should complain that you are trying to insert a record with an existsing PK. Check the DDL for the currency table. If the PK constraint is properly defined and this is still happening, then we have a wierd problem.
Shud we get the persistant object to be updated before assigning the new values? Is it compulsory?
Its not compulsory, but I can't think of a reason why you would not do it. Think about how database applications usually work - can you think of an occassion when you would try to update something without knowing if it were in the DB in the first place?
Originally posted by Tejo Kumar: Shud we get the persistant object to be updated before assigning the new values? Is it compulsory?
Yes, if you want to perform an update of only a few rows, you'll need to first select the original object. In SQL you'd merely tell it to update each column specifically, and the database would do exactly that. In Hibernate, however, here's what happens.
Create new object; values default to null or some other initial value.
Set some fields on the object.
Tell Hibernate to update the object.
Hibernate sees it has a PK and selects the original object
Hibernate compares your object to the original, updating all fields that differ.
Hibernate saves the new object.
In step 5, Hibernate takes all the "new" null values and pushes them to the object to be updated, thinking they are new values. Hibernate cannot tell that you didn't "specify them in the update clause." In other words, it doesn't know you didn't specifically call obj.setDateLastValuation(null). [ January 21, 2005: Message edited by: David Harkness ]