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 Wed, 29 Nov 2006 22:59:22 GMT
    [ 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: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org

View raw message