[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
