I did a lot of work to make cqlsh compatible with Python 3 (and also Python
2.7) under CASSANDRA-10190. CASSANDRA-10190 has been blocked by
CASSANDRA-14298, which got about two thirds of the cqlsh dtests to work.
If somebody could commit to reviewing CASSANDRA-14298, I'd be willing to
pick it back
Hi Patrick,
I can help with validating 14298. We recently merged in changes that got the
nosetests for cqlshlib working on trunk. The test failures are mostly due to
4.0 changes. We can either fix them and then migrate to Python 3 or we can
directly fix the test failures once we move to Python 3
I saw that thread and the tickets. They haven't had any activity recently.
Given that it is already Feb 2019 and Python 2.7 is getting close to EOL'd, I
think it's worth moving forward with deprecating Python 2.7 support and adding
3.0 support prior to 4.0 release. I am not sure what the timelin
This sounds like something you should report upstream as a bug to DataStax.
I’m unaware of any bugs in Cassandra mainline that cause this behaviour, but if
you can reproduce the creation of this partitions in 3.11.2, we can help to
diagnose the cause. But without source code it would be a fool’
Hi,
We are facing one weird issue for a long time.
High level table Defination: primary key
((column1,column2,column3),column4,colum5)
Issue: Generating very large partions repeatedly. Sometimes even 6GB for a
single partition.
Distribution: DSE 5.1
: Cassandra 3.11.2
After some deb
Previous discussion can be found here:
https://lists.apache.org/thread.html/cbc50f5ac085ac759b52eb7e87277a3b82e2773c6d507c4b525d@%3Cdev.cassandra.apache.org%3E
On 11.02.19 19:58, Ariel Weisberg wrote:
Hi,
Do you mean Python 2/3 compatibility?
This has been discussed earlier and I think t