[
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?
A>there 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.
B>there 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 Piston 8 1 5 Piston Ring 2 4
table data:-
id name qty parent id
1 Engine 1 -
2 Block 1 1
3 Cam Soft 2 1
4 Piston 8 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 emf threw exception.
so to keep things consistent, i had to add id attribute in company.xsd.
Now, as company.xsd has id attribute,
ExceptionTests.testMismatchedDataObjectModel had problem, as for
this test, we have to purposely have a data model mismatch (and the modified
company.xsd does not now
have the data model mismatch as now id is present.) so i had to add a new xsd ,
similar to company.xsd
but with missing id attribute and had to make
companynoidMappingWithConverters.xml to use this new
xsd
---------------------------------------------------------------------------------------------------
Regards,
Amita
> 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/[email protected]/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]
