[jira] [Commented] (DERBY-6968) Instability in DatabaseMetaDataTest.testGetBestRowIdentifier

2017-10-08 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/DERBY-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196356#comment-16196356
 ] 

ASF subversion and git services commented on DERBY-6968:


Commit 1811511 from [~rhillegas] in branch 'code/branches/10.14'
[ https://svn.apache.org/r1811511 ]

DERBY-6968: Port 1811510 from trunk to 10.14 branch.

> Instability in DatabaseMetaDataTest.testGetBestRowIdentifier
> 
>
> Key: DERBY-6968
> URL: https://issues.apache.org/jira/browse/DERBY-6968
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, Test
>Affects Versions: 10.14.1.0
>Reporter: Rick Hillegas
> Attachments: 10.14.1.testResults.0-failures, 
> derby-6968-01-aa-assertUnorderedResultSet.diff
>
>
> Ingo reports instabilities in his platform tests of the 10.14.1.0 release 
> candidate. He sees intermittent failures in 
> DatabaseMetaDataTest.testGetBestRowIdentifier and then subsequent failures 
> due to poor test case isolation in that test. The test case fails because 
> DatabaseMetaData.getBestRowIdentifier() sometimes returns rows in a different 
> order than the test expects.
> The JDBC contract for that method does not specify an order for the returned 
> rows. ORDER BY clauses appear on some but not all the catalog queries in 
> metadata.properties which define the Derby result.
> I see two ways to address this issue:
> 1) The test could be fixed so that it hand-sorts the returned rows in order 
> to guarantee deterministic results.
> 2) ORDER BY clauses could be added to all the implicated metadata queries.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (DERBY-6968) Instability in DatabaseMetaDataTest.testGetBestRowIdentifier

2017-10-08 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/DERBY-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196347#comment-16196347
 ] 

ASF subversion and git services commented on DERBY-6968:


Commit 1811510 from [~rhillegas] in branch 'code/trunk'
[ https://svn.apache.org/r1811510 ]

DERBY-6968: Attempt to fix instability in 
DatabaseMetaDataTest.getBestRowIdentifier(); commit 
derby-6968-01-aa-assertUnorderedResultSet.diff.

> Instability in DatabaseMetaDataTest.testGetBestRowIdentifier
> 
>
> Key: DERBY-6968
> URL: https://issues.apache.org/jira/browse/DERBY-6968
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, Test
>Affects Versions: 10.14.1.0
>Reporter: Rick Hillegas
> Attachments: 10.14.1.testResults.0-failures, 
> derby-6968-01-aa-assertUnorderedResultSet.diff
>
>
> Ingo reports instabilities in his platform tests of the 10.14.1.0 release 
> candidate. He sees intermittent failures in 
> DatabaseMetaDataTest.testGetBestRowIdentifier and then subsequent failures 
> due to poor test case isolation in that test. The test case fails because 
> DatabaseMetaData.getBestRowIdentifier() sometimes returns rows in a different 
> order than the test expects.
> The JDBC contract for that method does not specify an order for the returned 
> rows. ORDER BY clauses appear on some but not all the catalog queries in 
> metadata.properties which define the Derby result.
> I see two ways to address this issue:
> 1) The test could be fixed so that it hand-sorts the returned rows in order 
> to guarantee deterministic results.
> 2) ORDER BY clauses could be added to all the implicated metadata queries.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (DERBY-6968) Instability in DatabaseMetaDataTest.testGetBestRowIdentifier

2017-10-08 Thread Rick Hillegas (JIRA)

[ 
https://issues.apache.org/jira/browse/DERBY-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196344#comment-16196344
 ] 

Rick Hillegas commented on DERBY-6968:
--

Thanks for the quick review, Bryan. Tests passed cleanly for me on 
derby-6968-01-aa-assertUnorderedResultSet.diff.

> Instability in DatabaseMetaDataTest.testGetBestRowIdentifier
> 
>
> Key: DERBY-6968
> URL: https://issues.apache.org/jira/browse/DERBY-6968
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, Test
>Affects Versions: 10.14.1.0
>Reporter: Rick Hillegas
> Attachments: 10.14.1.testResults.0-failures, 
> derby-6968-01-aa-assertUnorderedResultSet.diff
>
>
> Ingo reports instabilities in his platform tests of the 10.14.1.0 release 
> candidate. He sees intermittent failures in 
> DatabaseMetaDataTest.testGetBestRowIdentifier and then subsequent failures 
> due to poor test case isolation in that test. The test case fails because 
> DatabaseMetaData.getBestRowIdentifier() sometimes returns rows in a different 
> order than the test expects.
> The JDBC contract for that method does not specify an order for the returned 
> rows. ORDER BY clauses appear on some but not all the catalog queries in 
> metadata.properties which define the Derby result.
> I see two ways to address this issue:
> 1) The test could be fixed so that it hand-sorts the returned rows in order 
> to guarantee deterministic results.
> 2) ORDER BY clauses could be added to all the implicated metadata queries.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (DERBY-6968) Instability in DatabaseMetaDataTest.testGetBestRowIdentifier

2017-10-08 Thread Bryan Pendleton (JIRA)

[ 
https://issues.apache.org/jira/browse/DERBY-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196319#comment-16196319
 ] 

Bryan Pendleton commented on DERBY-6968:


That patch looks fine to me, thanks for taking care of this. +1 from me.

Perhaps we should file a separate issue to track the apparent mismatch with the 
spec (ordering on SCOPE)?


> Instability in DatabaseMetaDataTest.testGetBestRowIdentifier
> 
>
> Key: DERBY-6968
> URL: https://issues.apache.org/jira/browse/DERBY-6968
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, Test
>Affects Versions: 10.14.1.0
>Reporter: Rick Hillegas
> Attachments: 10.14.1.testResults.0-failures, 
> derby-6968-01-aa-assertUnorderedResultSet.diff
>
>
> Ingo reports instabilities in his platform tests of the 10.14.1.0 release 
> candidate. He sees intermittent failures in 
> DatabaseMetaDataTest.testGetBestRowIdentifier and then subsequent failures 
> due to poor test case isolation in that test. The test case fails because 
> DatabaseMetaData.getBestRowIdentifier() sometimes returns rows in a different 
> order than the test expects.
> The JDBC contract for that method does not specify an order for the returned 
> rows. ORDER BY clauses appear on some but not all the catalog queries in 
> metadata.properties which define the Derby result.
> I see two ways to address this issue:
> 1) The test could be fixed so that it hand-sorts the returned rows in order 
> to guarantee deterministic results.
> 2) ORDER BY clauses could be added to all the implicated metadata queries.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (DERBY-6968) Instability in DatabaseMetaDataTest.testGetBestRowIdentifier

2017-10-08 Thread Rick Hillegas (JIRA)

[ 
https://issues.apache.org/jira/browse/DERBY-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196273#comment-16196273
 ] 

Rick Hillegas commented on DERBY-6968:
--

Hey Bryan,

Thanks for pointing out the ordering on the SCOPE column. The queries are not 
ordered by returned column name, which is what the test needs. They are not 
ordered by SCOPE either.

I can only guess at the purpose served by getBestRowIdentifier(). Maybe 
object-relational-mappers use the method in order to dream up object 
identifiers for updating/deleting rows in databases which don't have a 
system-supplied ROWID pseudo column. The following link was slightly useful: 
http://media.datadirect.com/download/docs/jdbc/alljdbc/index.html#page/jdbcconnect/using-getbestrowidentifier.html

Adding an ordering by SCOPE to DatabaseMetaData.getBestRowIdentifier() is 
probably warranted since it would bring us into better compliance with the JDBC 
contract. I don't think that it will improve the behavior of this test, though. 
I do see that similar problems were addressed by DERBY-6623. For those 
problems, Dag had another solution, a variation on (1):

3) Use JDBC.assertUnorderedResultSet()

Changing the order of the results returned by 
DatabaseMetaData.getBestRowIdentifier() would probably break the upgrade tests. 
That is because they end up running the current DatabaseMetaDataTest against 
old engines, and the old engines would still be returning results in the old 
order. We would still need to do (1) or (3) I think.


> Instability in DatabaseMetaDataTest.testGetBestRowIdentifier
> 
>
> Key: DERBY-6968
> URL: https://issues.apache.org/jira/browse/DERBY-6968
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, Test
>Affects Versions: 10.14.1.0
>Reporter: Rick Hillegas
> Attachments: 10.14.1.testResults.0-failures
>
>
> Ingo reports instabilities in his platform tests of the 10.14.1.0 release 
> candidate. He sees intermittent failures in 
> DatabaseMetaDataTest.testGetBestRowIdentifier and then subsequent failures 
> due to poor test case isolation in that test. The test case fails because 
> DatabaseMetaData.getBestRowIdentifier() sometimes returns rows in a different 
> order than the test expects.
> The JDBC contract for that method does not specify an order for the returned 
> rows. ORDER BY clauses appear on some but not all the catalog queries in 
> metadata.properties which define the Derby result.
> I see two ways to address this issue:
> 1) The test could be fixed so that it hand-sorts the returned rows in order 
> to guarantee deterministic results.
> 2) ORDER BY clauses could be added to all the implicated metadata queries.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (DERBY-6968) Instability in DatabaseMetaDataTest.testGetBestRowIdentifier

2017-10-07 Thread Bryan Pendleton (JIRA)

[ 
https://issues.apache.org/jira/browse/DERBY-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16195790#comment-16195790
 ] 

Bryan Pendleton commented on DERBY-6968:


Our results aren't ordered at all? Or they are only partially ordered?

The spec says: "They are ordered by SCOPE."

https://docs.oracle.com/javase/7/docs/api/java/sql/DatabaseMetaData.html#getBestRowIdentifier(java.lang.String,%20java.lang.String,%20java.lang.String,%20int,%20boolean)

So if we aren't ordering our results by the SCOPE column, that certainly seems 
incorrect.

Regarding your two suggestions, my instinct is to prefer improving the engine 
implementation over improving the test. I can't immediately think of a downside 
to making our implementation of getBestRowIdentifier deliver a tighter ordering 
than it currently does.

That said, I've never used getBestRowIdentifier, and the JDBC spec itself 
certainly doesn't provide much intuition about why I would want to, nor did I 
find any useful examples in a few minutes of idle searching. What the heck is 
this method used for, and why?


> Instability in DatabaseMetaDataTest.testGetBestRowIdentifier
> 
>
> Key: DERBY-6968
> URL: https://issues.apache.org/jira/browse/DERBY-6968
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, Test
>Affects Versions: 10.14.1.0
>Reporter: Rick Hillegas
> Attachments: 10.14.1.testResults.0-failures
>
>
> Ingo reports instabilities in his platform tests of the 10.14.1.0 release 
> candidate. He sees intermittent failures in 
> DatabaseMetaDataTest.testGetBestRowIdentifier and then subsequent failures 
> due to poor test case isolation in that test. The test case fails because 
> DatabaseMetaData.getBestRowIdentifier() sometimes returns rows in a different 
> order than the test expects.
> The JDBC contract for that method does not specify an order for the returned 
> rows. ORDER BY clauses appear on some but not all the catalog queries in 
> metadata.properties which define the Derby result.
> I see two ways to address this issue:
> 1) The test could be fixed so that it hand-sorts the returned rows in order 
> to guarantee deterministic results.
> 2) ORDER BY clauses could be added to all the implicated metadata queries.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)