[ http://issues.apache.org/jira/browse/TORQUE-69?page=comments#action_12454478 ] Thomas Fischer commented on TORQUE-69: --------------------------------------
To support updates without primary key, would have to remember the original values of all fields of the modified object, and query for the unmodified fields. Like update table1 set c1=modifiedValue1,c2=modifiedValue2 where c1=unmodifiedValue1 and c2=unmodifiedValue2. This is not currently done at the moment. Throwing an exception would be the second best solution in my opinion. > Record.save() may not work if there is no primary key but no error is thrown. > ----------------------------------------------------------------------------- > > Key: TORQUE-69 > URL: http://issues.apache.org/jira/browse/TORQUE-69 > Project: Torque > Issue Type: Bug > Components: Runtime > Affects Versions: 3.3 > Environment: WinXP / Java 1.5 / Tomcat 5.5 / MS SQL > Reporter: CG Monroe > Priority: Minor > > 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
