[ 
https://issues.apache.org/jira/browse/CASSANDRA-14534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Bannister resolved CASSANDRA-14534.
-------------------------------------------
    Resolution: Implemented

> cqlsh_tests/cqlsh_tests.py::TestCqlsh::test_describe is flaky
> -------------------------------------------------------------
>
>                 Key: CASSANDRA-14534
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14534
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: CQL
>         Environment: trunk running on Ubuntu 16.04 LTS
>            Reporter: Patrick Bannister
>            Priority: Minor
>              Labels: cqlsh, dtest, flaky-test, test
>             Fix For: 4.x
>
>
> *Summary:* test_describe in cqlsh_tests/cqlsh_tests.py::TestCqlsh is flaky. 
> The test is written to expect the objects of a keyspace to be 
> lexicographically sorted in DESCRIBE KEYSPACE output. However, this almost 
> never happens, because the sort order of objects in DESCRIBE KEYSPACE output 
> is arbitrary. I plan to modify the test to check for expected output without 
> requiring lexicographic sorting of items of the same type; this work would be 
> rolled up under other work in CASSANDRA-10190.
> This is happening in the Cassandra Python driver, in cassandra.metadata, in 
> the KeyspaceMetadata and TableMetadata classes. KeyspaceMetadata and 
> TableMetadata store their child objects in Python dictionaries, and when 
> generating DESCRIBE output, they visit their child objects in the order 
> returned by the values() function of each dictionary. The Python dictionary 
> values() function returns items in an arbitrary order, so they will not 
> necessarily come back sorted lexicographically as expected by the test.
> A simple fix for the test would be to change the way it checks for the 
> expected output so that the order of objects of the same type is no longer 
> important.
> As currently written, the test creates a keyspace like so:
>  
> {code:java}
> CREATE KEYSPACE test WITH REPLICATION = {'class' : 'SimpleStrategy', 
> 'replication_factor' : 1 };
> CREATE TABLE test.users ( userid text PRIMARY KEY, firstname text, lastname 
> text, age int);
> CREATE INDEX myindex ON test.users (age);
> CREATE INDEX "QuotedNameIndex" on test.users (firstName);
> CREATE TABLE test.test (id int, col int, val text, PRIMARY KEY(id, col));
> CREATE INDEX ON test.test (col);
> CREATE INDEX ON test.test (val){code}
>  
> It expects the output of DESCRIBE KEYSPACE test to appear in the following 
> order:
>  
> {code:java}
> CREATE KEYSPACE test...
> CREATE TABLE test.test...
> CREATE INDEX test_col_idx...
> CREATE INDEX test_val_idx...
> CREATE TABLE test.users...
> CREATE INDEX "QuotedNameIndex"...
> CREATE INDEX myindex...{code}
> But as described above, tables aren't sorted lexicographically, and a table's 
> indexes aren't sorted lexicographically, so output for table test.users can 
> come before output for table test.test, and output for index test_val_idx can 
> come before output for index test_col_idx. The planned change to the test 
> would make it so that the test passes regardless of the order of these like 
> objects.
> If lexicographic sorting of objects of like type actually is a requirement 
> for DESCRIBE KEYSPACE, then we could fix this by modifying cqlsh 
> (duplicative, but simple), or by modifying the Cassandra Python driver's 
> cassandra/metadata.py script file (less duplicative but more difficult to 
> distribute).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to