Hi Adriano,
There are test cases like - testReadOrdersAndDetails2(
org.apache.tuscany.das.rdb.test.CompoundKeyTests)
which were failing when the code was throwing exception for any null data in
PK. With the
OUTER JOIN logic (no exception when all columns are null including PK , just
omit the DO),
In RDBMS and in DAS OUTER JOINs are used quite frequently. By definition
it means, all rows from parent and matching rows from child. So, there is a
chance for having complete null rows from child and that is the purpose of
OUTER JOIN.
So there are different situations
1) complete child row is
Hi Amita,
Great work you are doing : ). You are correct about the outer join case, I
hadn't remember this use case. Yes, DAS should ignore a row completely null,
but only when it's completely null, any other data in it, DAS should throw
an exception.
Thanks for the explanation about the static
There is a bit of confusion around the RecursiveTests.testReadEngineParts()
, in the context of this fix.
Below is the data for tables, queries etc.
sql return:-
*1 Engine 1 - 2 Block 1 1 -
- - -
*1 Engine 1 - 3 Cam Soft 2
Yes, I think it should fail, once DAS shouldn't omit a data from the user.
Cause, if the pk has null pk, it means it doesn't have an id and cannot be
guaranteed its uniqueness. I think maybe DAS should not throw the exception,
but needs to warn the user when any row is omitted, however I don't
It seems ok Amita ; )
Adriano Crestani
On 7/27/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
Hi Adriano,
Yes, so in summary , trying to do following -
1) select missing complete or partial PK for any of the tables involved-
exception
2) if any table in select has no PK in config and no ID
I had the same problem on DAS C++, now it's throwing an exception when it
finds a row that does not contain all the pk columns.
I'm not used to the DAS Java, but I will explain how I did it on DAS C++,
maybe this can help you ; )
It reads the ResultSet metadata to find the pk columns. If the PK
Hi Adriano,
Yes, so in summary , trying to do following -
1) select missing complete or partial PK for any of the tables involved-
exception
2) if any table in select has no PK in config and no ID column in
config/select - exception
3) if any table in select has no PK in config and has ID column
Further on this,
Need to consider single and compound PKs case.
When select does not include complete PK (all PK columns from compound PK) ,
DAS needs to throw exception.
As a fix proposing below changes:-
AIn ResultMetadata - introduce new HashMap tableToPrimaryKeys , fill it
during constuctor
Sorry for the leng thy mail
Tried to check the case when the database has parent-child tables and DAS
SELECT Command may/may not
contain the PKs of the tables. And found some quite confusing cases/results,
which are effectively giving
user a wrong impression of the data in tables.
Looks
Amita,
Definitely, the DAS should enforce the requirement that the PK should
be returned for each table in the results. I would consider this a
case where the DAS should throw an exception.
Brent
On 7/18/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
Sorry for the leng thy mail
Tried to
Amita,
There is now way for DAS to keep the relationship data consistence if
both, pk and fk, are not completely defined. Without them DAS cannot predict
the relationship.
As Brent said, I think it could throw an exception when the PK is missing,
no matter if there are relationships or not.
It is best to throw an exception for PK not being there, otherwise an empty
result set can have two meaning:Empty or something went wrong
On 7/18/07, Adriano Crestani [EMAIL PROTECTED] wrote:
Amita,
There is now way for DAS to keep the relationship data consistence if
both, pk and fk, are
13 matches
Mail list logo
