You are viewing a plain text version of this content. The canonical link for it is here.
Posted to torque-dev@db.apache.org by "Thomas Fischer (JIRA)" <ji...@apache.org> on 2006/12/18 13:19:26 UTC

[jira] Commented: (TORQUE-69) Record.save() may not work if there is no primary key but no error is thrown.

    [ http://issues.apache.org/jira/browse/TORQUE-69?page=comments#action_12459285 ] 
            
Thomas Fischer commented on TORQUE-69:
--------------------------------------

After discussion on the mailing list whether to maintain field state, the exception seems the only sensible thing to to before the 3.3 release.
I'd suggest to always throw an Exception in the Peer's doUpdate(Criteria,connection) method if no primary key exists.

> 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: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org