db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Fischer (JIRA)" <j...@apache.org>
Subject [jira] Commented: (TORQUE-69) Record.save() may not work if there is no primary key but no error is thrown.
Date Mon, 18 Dec 2006 12:19:26 GMT
    [ 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

View raw message