[jira] Commented: (TUSCANY-1464) Wrong query results when SELECT misses PKs
[
https://issues.apache.org/jira/browse/TUSCANY-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518670
]
Adriano Crestani commented on TUSCANY-1464:
---
- On code below, it checks for the fk COC that is table_id, however this code
will take _id as fk, but there is no table name before the '_'. I think the
condition below should be = 1 instead of 0.
ResultMetadata Constructor:
...
String colName = ;
if (columnName.indexOf(_ID) = 0) {
...
-Another doubt, is the String column name always upper case? Otherwise the
indexof will look for the _ID on sensitive case mode, when it shouldn't.
- Why do you check for null pks twice on method
ResultSetProcessor.addRowToGraph?
if (!rawDataFromRow.hasValidPrimaryKey() ||
(rawDataFromRow.hasNullPrimaryKey()
!rawDataFromRow.isTableEmpty())) {//some PK null , but other data present
//continue; - need to throw exception as anyway the result will
give a wrong impression
//when any one table in result set misses PK column or has null
value in PK column
throw new RuntimeException(Table
+rawDataFromRow.getTableName()+ in query does not include Primary Key +
column or has null value in it, can not
proceed!);
}
String tableName = rawDataFromRow.getTableName();
DataObject tableObject = registry.get(tableName,
rawDataFromRow.getPrimaryKeyValues());
if (tableObject == null
rawDataFromRow.getPrimaryKeyValues() != null
!rawDataFromRow.getPrimaryKeyValues().contains(null)
rawDataFromRow.getPrimaryKeyValues().size() 0)
{//2nd check for null data in PK,
//as TableData.addData() - hasValidPrimaryKey=false is
commented for a reason
//with this, DataObjs with null PK will not be added to
registry and tableObjects
tableObject = doMaker.createAndAddDataObject(rawDataFromRow,
resultMetadata);
if (this.logger.isDebugEnabled()) {
this.logger.debug(Putting table + tableName + with PK
+ rawDataFromRow.getPrimaryKeyValues() + into
registry);
}
registry.put(tableName, rawDataFromRow.getPrimaryKeyValues(),
tableObject);
}
else{
if (this.logger.isDebugEnabled()) {
this.logger.debug(Not Null tableObject or NULL PK);
}
}
I applied the patch on trunk, but when mvn compiled there was a class using
ResultDescriptor.getColumnIndex method, but this getter was only added on patch
from JIRA 1465. Then I applied both, 1464 and then 1465, is it ok? Perhaps, the
mvn tests failed on test:
FAILURE!
testReplaceResultDescriptor(org.apache.tuscany.das.rdb.test.DynamicResultDescrip
torTests) Time elapsed: 0.02 sec FAILURE!
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertTrue(Assert.java:27)
at org.apache.tuscany.das.rdb.test.DynamicResultDescriptorTests.testRepl
aceResultDescriptor(DynamicResultDescriptorTests.java:147)
at org.apache.tuscany.das.rdb.test.DynamicResultDescriptorTests.testRepl
aceResultDescriptor(DynamicResultDescriptorTests.java:147)
I don't know if I did something wrong, but I will try it tomorrow, needing to
sleep now ; )
Regards,
Adriano Crestani
Wrong query results when SELECT misses PKs
--
Key: TUSCANY-1464
URL: https://issues.apache.org/jira/browse/TUSCANY-1464
Project: Tuscany
Issue Type: Bug
Components: Java DAS RDB
Affects Versions: Java-DAS-Next
Reporter: Amita Vadhavkar
Assignee: Amita Vadhavkar
Fix For: Java-DAS-Next
Attachments: 1464.patch, 1464.patch, 1464.patch
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20322.html
Fix the bug uncovered in above mail discussion.
--
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]
[jira] Commented: (TUSCANY-1464) Wrong query results when SELECT misses PKs
[ https://issues.apache.org/jira/browse/TUSCANY-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517631 ] Adriano Crestani commented on TUSCANY-1464: --- Replies on http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20244.html Wrong query results when SELECT misses PKs -- Key: TUSCANY-1464 URL: https://issues.apache.org/jira/browse/TUSCANY-1464 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1464.patch, 1464.patch http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20322.html Fix the bug uncovered in above mail discussion. -- 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]
[jira] Commented: (TUSCANY-1464) Wrong query results when SELECT misses PKs
[
https://issues.apache.org/jira/browse/TUSCANY-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517158
]
Amita Vadhavkar commented on TUSCANY-1464:
--
1 - On method ResultMetadata.getAllPKsForTable(String tableName), I understand
that you return an empty Set when there is no column in config, but why you add
an empty String on it?
Athere is a case when table does not have entry in cfg and is used in select.
also, there is no column
in select clause with name 'id' (ignore casesensitivity). so das logic can not
get a list of pks
for this table and treats all columns appearing in the select as pks. Check
ResultMetadata.isPKColumn()
(pre-existing method). Here when there are no columns in config, it returns
true. for this, in
ResultMetadata.getAllPKsForTable(String tableName), i am putting in the pk map
- table entry key with null
value against it.And so, getAllPKsForTable() will return null. After that , in
ResultSetRow.checkResultSetMissesPK(), when this null is detected, i set,
tableRShasPK to true. so this is
one classic case when all columns should be pks.
Bthere is another case when there is a table entry in cfg and has some columns
defed in it, but none is
set to pk, and also, there is no id column in cfg or in result set. in this
case, there is no entry
made in pk map. As there is no entry in map
ResultMetadata.getAllPKsForTable(String tableName)
will again return null, and there will be no way to distinguish this case from
the above classic case
(all cols are pks). so in order to distinguish, i am returning a hash with only
one entry . I have
a comment inline in getAllPKsForTable() where i am doing this. After that, in
checkResultSetMissesPK(),
when this condition is detected, set tableRShasPK to false.
so, basically das logic so far is such that, when possible give advantage of
doubt that the table
will have pk (A), but when user has explicitly defed columsn and table in cfg
and still has not
configed any column as pk, treat it differently(B) and if COC also is not able
to get a PK, treat
B as missing pk case and throw exception.
-
2 - On ResultSetProcessor, shouldn't be thrown an exception when the table has
pk but this pk is null instead of just ignoring the row?
sql return:-
*1 Engine 1 - 2 Block 1 1 - - - -
*1 Engine 1 - 3 Cam Soft 2 1 - - - -
1 Engine 1 -4 Piston8 1 5 Piston Ring 2 4
table data:-
id name qty parent id
1 Engine1 -
2 Block 1 1
3 Cam Soft 2 1
4 Piston8 1
5 Piston Ring 2 4
query:-
SELECT
P1.ID,
P1.NAME,
P1.QUANTITY,
P1.PARENT_ID,
P2.ID,
P2.NAME,
P2.QUANTITY,
P2.PARENT_ID,
P3.ID,
P3.NAME,
P3.QUANTITY,
P3.PARENT_ID
FROM
APP.PART AS P1 LEFT OUTER JOIN APP.PART AS P2
ON P1.ID = P2.PARENT_ID
LEFT OUTER JOIN APP.PART AS P3
ON P2.ID = P3.PARENT_ID
WHERE
P1.ID = 1
see the recursiveTests. here the recursion occurs 3 times on the same (part)
table and total 5 DOs
should be formed in mem. (pre-existing case).
now see ResultSetProcessor.addRowToGraph(). if we take null data in pk as
exception, the rows from
sql return above marked with *, will cause the whole query to fail. instead ,
if we go past the
exception (by not setting flag to false for null pk), we can ensure ahead that
DOs will null
PK do not enter registry.
the below check in ResutlSetProcessor.addRowToGraph() does this.
if (tableObject == null
!rawDataFromRow.getPrimaryKeyValues().contains(null)) {//2nd check for null
data in PK,
with this check, in the recursive test case as well as other cases when the pk
is null value, DO will
not form and will not enter table registry and so in tableObjects(RowObject)
collection. Also, as it
is not in tableObjects, no relationship will be processed on it (so child table
rows will not come in).
But, even I concur with you, that to keep things clean, we can make
RecursiveTests fail and clear cut
throw exception for any occurence of null data in PK. Any idea about the
reason for the RecursiveTests?
I am sending a mail to ML, lets see the replies(you also give your view there
please) and based on that
I will correct this portion of code.
--
3- Sorry, but I didn't get why you added the ID attribute on company.xsd : (
this xsd is used in companytests. so far, as we were allowing missing pks in
select, this was
working without failure. but with 1464, the selects had to be changed to add PK
columns. Now with
this change, the xsd and selects had mismatch, because id was missing in xsd
and
[jira] Commented: (TUSCANY-1464) Wrong query results when SELECT misses PKs
[ https://issues.apache.org/jira/browse/TUSCANY-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517162 ] Adriano Crestani commented on TUSCANY-1464: --- 1- OK 2 - commented on ML 3- As ID column being considered primary key is a Convention Over Configuration issue, I think the user shouldn't need to declare it anywhere, cause DAS should recognize it anyway. What do you think? Regards, Adriano Crestani Wrong query results when SELECT misses PKs -- Key: TUSCANY-1464 URL: https://issues.apache.org/jira/browse/TUSCANY-1464 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1464.patch http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20322.html Fix the bug uncovered in above mail discussion. -- 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]
[jira] Commented: (TUSCANY-1464) Wrong query results when SELECT misses PKs
[ https://issues.apache.org/jira/browse/TUSCANY-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517084 ] Adriano Crestani commented on TUSCANY-1464: --- reviewing patch ; ) Adriano Crestani Wrong query results when SELECT misses PKs -- Key: TUSCANY-1464 URL: https://issues.apache.org/jira/browse/TUSCANY-1464 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1464.patch http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20322.html Fix the bug uncovered in above mail discussion. -- 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]
