Details
Minor Description
Here's the situation.
You have a table with no primary key. E.g. A table named Poor_Design with columns: FK1, FK2, Value1, Value2.
You then retrieve a record object from that table, modify it, and then save it, e.g.
Criteria c = new Criteria();
c.add(PoorDesignPeer.FK1, fk1);
c.add(PoorDesignPeer.FK2, fk2);
List result = PoorDesignPeer.doSelect(c);
PoorDesign modifiedRec = (PoorDesign) results.get(0);
modifiedRec.setValue1(newValue);
modifiedRec.save();
The save() ( UPDATE ) to the DB will not suceed, but no error will be thrown indicating it failed.
This also occur if PoorDesignPeer.doUpdate(modifiedRec) is used.
This condition should probably throw an error in all cases, since there is no reliable way to locate the original record in the DB.
In trying to trace it out, I suspect that there is probably some logic bug in the underlying BasePeer object. This is probably related to the buildcriteria(object) not being able to identify modified fields from unmodified and therefore
creating a criteria for a record that can't be retrieved again at lower levels. But the logic for this is complicated.
However, an easy way to fix this might be to just update the generated peer's doUpdate( object ) method to check for primary keys or not, and throw an exception here all the time.