[
https://issues.apache.org/jira/browse/CASSANDRA-14534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Bannister updated CASSANDRA-14534:
------------------------------------------
Issue Type: Sub-task (was: Test)
Parent: CASSANDRA-10190
> 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: [email protected]
For additional commands, e-mail: [email protected]
