db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "CG Monroe (JIRA)" <j...@apache.org>
Subject [jira] Commented: (TORQUE-113) doDelete with invalid column should throw exception, not delete all rows
Date Fri, 18 Apr 2008 16:28:21 GMT

    [ https://issues.apache.org/jira/browse/TORQUE-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590502#action_12590502

CG Monroe commented on TORQUE-113:

I think part of the underlying problems people are seeing might be due to the Torque-44. 
This was released in 3.3-RC1 in Nov 2006.  It basically causes the DB id strings (tables,
names, etc), to use the exact same case as is defined in the XML.  

Good news is that there is a new generator option, torque.deprecated.uppercasePeer which can
be set to true to revert to the original behaviour.

Doesn't fix this problem, but might be a quick way around it.

Carl... you should take a look at the Map objects generated with the record objects.  All
the information defined in XML is now available there. Using these would be a much more generic
way to find your primary keys.

As to case insensitivity, yes there are a lot of issues around this.  But there may also be
some low hanging areas we could improve on.  One area I've thought about doing this is to
"normalize" the key names used in the Map objects.  E.g., change the add and find methods
to convert the keys to all one case.  This is in line with the SQL standard and would only
effect non-standard case sensitive situation where someone has two tables or columns with
the same name but with different case.  (Which, IMHO, is REALLY bad schema design...) 

Another place is the getByName methods in the record objects. It wouldn't be hard to do some
normalization here as well.

> doDelete with invalid column should throw exception, not delete all rows
> ------------------------------------------------------------------------
>                 Key: TORQUE-113
>                 URL: https://issues.apache.org/jira/browse/TORQUE-113
>             Project: Torque
>          Issue Type: Bug
>          Components: Runtime
>    Affects Versions: 3.3
>            Reporter: Julian Zinn
>             Fix For: 3.3, 4.0
> The following (incorrect) client code should cause an exception to be thrown.  Instead
of an exception, all rows in table T1 are deleted.
> {code}
> T1Peer.doDelete(new Criteria().add(T2Peer.COL, 2));
> {code}
> This code appeared in a project I am working on.  The intent was to delete rows from
table T2.
> Before the fix for TORQUE-93, this code had the intended effect becaue {{T1Peer.doDelete(criteria)}}
just passed the criteria object to {{BasePeer.doDelete(criteria)}}.  Since the only reference
BasePeer had to a table was table T2 in the criteria, only rows in table T2 were deleted.
> Now that {{T1Peer.doDelete(criteria)}} calls {{BasePeer.doDelete(criteria, TABLE_NAME)}}
instead, the test {{if (crit.containsKey(key))}} in {{BasePeer.processTables()}} always fails.
 This leads to an empty where clause, causing all rows in table T1 to be deleted.
> *Expect*: All Criterion objects in a Criteria should be used in the final where clause.
 If not, an exception should be thrown.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org

View raw message