[jira] [Comment Edited] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805523#comment-16805523 ] Dinesh Joshi edited comment on CASSANDRA-10190 at 3/29/19 10:42 PM: Hi [~riley.mcdowell], Patrick & I had a chat and we will be first bringing the Python 3 implementation in line with the Python 2.7 which means if there are tests that are currently broken, we won't fix them as long as the failures are the same. Once we have a better insight into what the failures are about, we will go in and fix whatever is possible without touching the driver. Finally, extracting the checked in driver is something we'll look into. But that is a long poll and strictly not needed for Python 3 compatibility. was (Author: djoshi3): Hi [~riley.mcdowell], Patrick & I had a chat and we will be first bringing the Python 3 implementation in line with the Python 2.7 which means if there are tests that are currently broken, we won't fix them as long as the failures are the same. Once we have a better insight into what the failures are about, we will go in and fix whatever is possible without touching the driver. Finally, extracting the checked in driver is something we'll look into this. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- 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
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805523#comment-16805523 ] Dinesh Joshi commented on CASSANDRA-10190: -- Hi [~riley.mcdowell], Patrick & I had a chat and we will be first bringing the Python 3 implementation in line with the Python 2.7 which means if there are tests that are currently broken, we won't fix them as long as the failures are the same. Once we have a better insight into what the failures are about, we will go in and fix whatever is possible without touching the driver. Finally, extracting the checked in driver is something we'll look into this. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- 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
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805519#comment-16805519 ] Riley McDowell commented on CASSANDRA-10190: [~ptbannister] The contributions to the upstream driver might take a while. Would you consider # Moving forward with the Python3 cqlsh support as-is to push for a release, and # Also opening two additional, smaller tickets to resolve those two failing tests? > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- 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
[jira] [Updated] (CASSANDRA-15052) Dtests: Add acceptable warnings to offline tool tests in order to pass them
[ https://issues.apache.org/jira/browse/CASSANDRA-15052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-15052: - Status: Awaiting Feedback (was: Triage) > Dtests: Add acceptable warnings to offline tool tests in order to pass them > --- > > Key: CASSANDRA-15052 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15052 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > I run all dtest suite and test > offline_tools_test.py::TestOfflineTools::test_sstablelevelreset has failed > because of additional warning logs which were not added into acceptable ones. > After adding them, test passed fine. I believe added warning messages have > nothing to do with test itself, it was reproduced on c5.9xlarge as well as no > "regular" notebook. > > https://github.com/apache/cassandra-dtest/pull/47 -- 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
[jira] [Commented] (CASSANDRA-15052) Dtests: Add acceptable warnings to offline tool tests in order to pass them
[
https://issues.apache.org/jira/browse/CASSANDRA-15052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805507#comment-16805507
]
Dinesh Joshi commented on CASSANDRA-15052:
--
Hi [~stefan.miklosovic], I got around to checking this out and I can't seem to
repro the issue. {{offline_tools_test.py::test_sstablelevelreset}} passes for
me. I don't see a failure. Here's how I ran it locally (within a virtualenv):
{noformat}
pytest --cassandra-dir=/home/dj/cassandra -s -k test_sstablelevelreset
{noformat}
I am running this against latest trunk @
df8e068c721d503e5f72a397c393c3034ecccef3.
> Dtests: Add acceptable warnings to offline tool tests in order to pass them
> ---
>
> Key: CASSANDRA-15052
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15052
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I run all dtest suite and test
> offline_tools_test.py::TestOfflineTools::test_sstablelevelreset has failed
> because of additional warning logs which were not added into acceptable ones.
> After adding them, test passed fine. I believe added warning messages have
> nothing to do with test itself, it was reproduced on c5.9xlarge as well as no
> "regular" notebook.
>
> https://github.com/apache/cassandra-dtest/pull/47
--
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
[jira] [Commented] (CASSANDRA-15064) Wrong ordering for timeuuid fields
[
https://issues.apache.org/jira/browse/CASSANDRA-15064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805425#comment-16805425
]
Jon Meredith commented on CASSANDRA-15064:
--
Thinking a little more on this, if you went with using server-side now() you'd
need to ensure the same node was used to coordinate all of the INSERTs and I'm
not sure what the default behavior of the Go client is, so perhaps doing
something client side would be best.
> Wrong ordering for timeuuid fields
> --
>
> Key: CASSANDRA-15064
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15064
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Andreas Andersen
>Assignee: Jon Meredith
>Priority: Normal
> Attachments: example.cql
>
>
> Hi!
> We're seeing some strange behavior for the ordering of timeuuid fields. They
> seem to be sorted in the wrong order when the clock_seq_low field in a
> timeuuid goes from 7f to 80. Consider the following example:
> {noformat}
> cqlsh:test> show version;
> [cqlsh 5.0.1 | Cassandra 3.11.4 | CQL spec 3.4.4 | Native protocol v4]
> cqlsh:test> CREATE TABLE t (
> ... partition int,
> ... t timeuuid,
> ... i int,
> ...
> ... PRIMARY KEY(partition, t)
> ... )
> ... WITH CLUSTERING ORDER BY(t ASC);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b57e-f0def1d0755e, 1);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b57f-f0def1d0755e, 2);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b580-f0def1d0755e, 3);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b581-f0def1d0755e, 4);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b582-f0def1d0755e, 5);
> cqlsh:test> SELECT * FROM t WHERE partition = 1 ORDER BY t ASC;
>
> partition | t | i
> ---+--+---
> 1 | 84e2c963-4ef9-11e9-b580-f0def1d0755e | 3
> 1 | 84e2c963-4ef9-11e9-b581-f0def1d0755e | 4
> 1 | 84e2c963-4ef9-11e9-b582-f0def1d0755e | 5
> 1 | 84e2c963-4ef9-11e9-b57e-f0def1d0755e | 1
> 1 | 84e2c963-4ef9-11e9-b57f-f0def1d0755e | 2
>
> (5 rows)
> cqlsh:test>
> {noformat}
> The expected behavior is that the rows are returned in the same order as they
> were inserted (we inserted them with their clustering key in an ascending
> order). Instead, the order "wraps" in the middle.
> This issue only arises when the 9th octet (clock_seq_low) in the uuid goes
> from 7f to 80. A guess would be that the comparison is implemented as a
> signed integer instead of an unsigned integer, as 0x7f = 127 and 0x80 = -128.
> According to the RFC, the field should be treated as an unsigned integer:
> [https://tools.ietf.org/html/rfc4122#section-4.1.2]
> Changing the field from a timeuuid to a uuid gives the expected correct
> behavior:
> {noformat}
> cqlsh:test> CREATE TABLE t (
> ... partition int,
> ... t uuid,
> ... i int,
> ...
> ... PRIMARY KEY(partition, t)
> ... )
> ... WITH CLUSTERING ORDER BY(t ASC);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b57e-f0def1d0755e, 1);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b57f-f0def1d0755e, 2);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b580-f0def1d0755e, 3);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b581-f0def1d0755e, 4);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b582-f0def1d0755e, 5);
> cqlsh:test> SELECT * FROM t WHERE partition = 1 ORDER BY t ASC;
>
> partition | t | i
> ---+--+---
> 1 | 84e2c963-4ef9-11e9-b57e-f0def1d0755e | 1
> 1 | 84e2c963-4ef9-11e9-b57f-f0def1d0755e | 2
> 1 | 84e2c963-4ef9-11e9-b580-f0def1d0755e | 3
> 1 | 84e2c963-4ef9-11e9-b581-f0def1d0755e | 4
> 1 | 84e2c963-4ef9-11e9-b582-f0def1d0755e | 5
>
> (5 rows)
> cqlsh:test>{noformat}
>
>
--
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
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805188#comment-16805188 ] Dinesh Joshi commented on CASSANDRA-10190: -- [~ptbannister] could you please post your branch? Like we discussed, the driver that cqlsh uses is checked in [here|https://github.com/apache/cassandra/blob/trunk/lib/cassandra-driver-internal-only-3.12.0.post0-5838e2fd.zip]. We probably need to change that. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- 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
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805180#comment-16805180 ] Patrick Bannister commented on CASSANDRA-10190: --- Update on the tests: I have everything passing, except for some problems that appear rooted in the driver: * cassandra-dtest cqlsh_tests/test_cqlsh_copy.py TestCqlshCopy test_unusual_dates: the driver is choking when it tries to read dates after the year 1. * cqlshlib tests pylib/cqlshlib/test/test_cqlsh_output.py TestCqlshOutput test_user_types_output: the driver is choking when it tries to read a user defined type for a frozen set with nulls. Python does not support ordering a collection with null values (NoneType). I don't believe either of these problems can be solved with cqlshlib alone. Probably we would need to contribute to the driver to resolve them. My feeling is that both of these problems are blockers. Any input from our watchers? > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- 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
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805177#comment-16805177 ] Dinesh Joshi commented on CASSANDRA-10190: -- [~sangrampatil] this is complex piece and I am not sure if we will back port it the older releases. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- 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
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805175#comment-16805175 ] Patrick Bannister commented on CASSANDRA-10190: --- It's difficult to provide an ETA. This is a big ticket, and most of us are working on a volunteer basis. The best I can say is that I've heard there's a lot of interest in this ticket, and that should provide some motivation to get it done. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- 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
[jira] [Commented] (CASSANDRA-15064) Wrong ordering for timeuuid fields
[
https://issues.apache.org/jira/browse/CASSANDRA-15064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805069#comment-16805069
]
Jon Meredith commented on CASSANDRA-15064:
--
Thanks for the additional information. I'm not familiar with the Go client so
thanks for the link. The Go client takes a different approach to UUID
generation than the server-side now() function, which as I mentioned above,
generates the clockseq once at startup time - which limits now() to generating
a single UUID per 100ns (which is 10 million / second).
I agree with you you'll get a wrapping problem with your UUID solution. It
just takes the lower 14 bits from the 32-bit clockseq counter which obviously
wraps.
What do you think about these two possibilities
# Insert using CQL now() - probably easiest
# Write an alternate UUIDFromTime
*Insert Using CQL now()*
{noformat}
INSERT INTO timeline(user_id, image_timestamp, image_id) VALUES(?, now(), ?)
{noformat}
That will generate timestamps that always sort as you expect, however you'll
need an average insertion rate less than 10,000,000 / second / coordinator and
move the cost of UUID generation from client to server which should be small.
*Write an alternate UUIDFromTime to match server-side now()*
It should be straightforward to provide an alternative UUIDFromTime with the
same semantics as CQL now().
Initialize clockseq once at startup
Keep an atomic 64-bit, lastNanos, to store the 60-bit UUID timestamp
Atomically update to be monontonically increasing.
Something like this (apologies for the pigeon Go, I don't normally write it and
have not tested this fragment)
{noformat}
var currentNanos = atomic.LoadInt64()
// compute nextNanos the same way as
https://github.com/gocql/gocql/blame/master/uuid.go#L126
var nextNanos = int64(utcTime.Unix()-timeBase)*1000 +
int64(utcTime.Nanosecond()/100)
if (thisNanos <= currentNanos) {
thisNanos = currentNanos + 1; // If the clock is drifting backwards, just
pick the monontonic next timestamp
}
if(!atomic.CompareAndSwapUInt64(, currentNanos, nextNanos)) {
// If unable to swap, another thread has generated a new UUID, so the
time should be close
// to when this thread would have, just take the next timestamp rather
than loop forever
// in case of high contention.
thisNanos = atomic.AddInt64(, 1)
}
{noformat}
What do you think?
As for this JIRA, what I'd propose is that I'll submit documentation
improvements so that users don't rely on TimeUUID clockseq sort order, and file
an issue under the GoCql client driver in case they missed this JIRA.
> Wrong ordering for timeuuid fields
> --
>
> Key: CASSANDRA-15064
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15064
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Andreas Andersen
>Assignee: Jon Meredith
>Priority: Normal
> Attachments: example.cql
>
>
> Hi!
> We're seeing some strange behavior for the ordering of timeuuid fields. They
> seem to be sorted in the wrong order when the clock_seq_low field in a
> timeuuid goes from 7f to 80. Consider the following example:
> {noformat}
> cqlsh:test> show version;
> [cqlsh 5.0.1 | Cassandra 3.11.4 | CQL spec 3.4.4 | Native protocol v4]
> cqlsh:test> CREATE TABLE t (
> ... partition int,
> ... t timeuuid,
> ... i int,
> ...
> ... PRIMARY KEY(partition, t)
> ... )
> ... WITH CLUSTERING ORDER BY(t ASC);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b57e-f0def1d0755e, 1);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b57f-f0def1d0755e, 2);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b580-f0def1d0755e, 3);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b581-f0def1d0755e, 4);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b582-f0def1d0755e, 5);
> cqlsh:test> SELECT * FROM t WHERE partition = 1 ORDER BY t ASC;
>
> partition | t | i
> ---+--+---
> 1 | 84e2c963-4ef9-11e9-b580-f0def1d0755e | 3
> 1 | 84e2c963-4ef9-11e9-b581-f0def1d0755e | 4
> 1 | 84e2c963-4ef9-11e9-b582-f0def1d0755e | 5
> 1 | 84e2c963-4ef9-11e9-b57e-f0def1d0755e | 1
> 1 | 84e2c963-4ef9-11e9-b57f-f0def1d0755e | 2
>
> (5 rows)
> cqlsh:test>
> {noformat}
> The expected behavior is that the rows are returned in the same order as they
> were inserted (we inserted them with their clustering key in an ascending
> order). Instead, the order "wraps" in the middle.
>
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805044#comment-16805044 ] Sangram Patil commented on CASSANDRA-10190: --- [~ptbannister] Thanks for the updates. Could you please share the ETA for cqlsh for python3. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- 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
[jira] [Commented] (CASSANDRA-14990) Move cqlsh tests to dtest repo
[ https://issues.apache.org/jira/browse/CASSANDRA-14990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804996#comment-16804996 ] Patrick Bannister commented on CASSANDRA-14990: --- [~djoshi3], some of the cqlshlib test files are nothing but stubs. Why don't we remove them? * pylib/cqlshlib/tests/test_cqlsh_commands.py * pylib/cqlshlib/tests/test_cqlsh_invocation.py * pylib/cqlshlib/tests/test_cqlsh_parsing.py > Move cqlsh tests to dtest repo > -- > > Key: CASSANDRA-14990 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14990 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest, Tool/cqlsh >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Low > > The cqlsh tests are split into the dtest repo and the main Cassandra repo. We > should move them to dtests repo and migrate them from nosetests to pytests. -- 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
[jira] [Commented] (CASSANDRA-15064) Wrong ordering for timeuuid fields
[
https://issues.apache.org/jira/browse/CASSANDRA-15064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804990#comment-16804990
]
Andreas Andersen commented on CASSANDRA-15064:
--
The problem is a real world problem for us, and the timeuuid's in the example
are not synthetic. We use the gocql client library for golang, which generates
timeuuid's in this way. It's the function at
https://github.com/gocql/gocql/blob/master/uuid.go#L121 we use to generate our
timeuuid's from timestamps, and we rely on the sequence number to be
incremented on each call.
Our use case is sorting images on a timeline. Our table more or less look like:
{noformat}
CREATE TABLE timeline (
user_id uuid,
image_timestamp timeuuid,
image_id uuid,
-- Lots of other metadata fields here...
PRIMARY KEY(user_id, image_timestamp)
)
WITH CLUSTERING ORDER BY(t ASC);
{noformat}
The images are sorted by the time that they were taken. However, images taken
quickly in series by the same camera might all have equal timestamps. In this
case, we want to order them by some other property to show them in the correct
chronological order. As of today we use the filename for this. In order to keep
the table structure simple, we just sort them in the correct order before
inserting them, relying on each newly generated timeuuid being greater than the
last one. Our client side code more or less look like:
{noformat}
type image struct {
user_id uuid
image_iduuid
taken_attimestamp
filenamestring
}
images := []image
// Sort images in the order we want to store them in cassandra
sort(images, [taken_at, filename])
// Now give every image a unique timeuuid and insert them into cassandra. We
// rely on the timeuuid generator to generate id's in ascending order in case of
// multiple images with the same timestamp.
for i := range images {
image_timestamp := uuidFromTime(i.taken_at)
queryCassandra(
"INSERT INTO timeline(user_id, image_timestamp, image_id) VALUES(?, ?,
?)",
i.user_id, image_timestamp, i.image_id
)
}
{noformat}
Our use case is kind of special, since we at the time of insertion have all
images that will ever be created for a single user, which allows us to insert
them in this way. Creating a table in the following way would give us the same
result:
{noformat}
CREATE TABLE timeline (
user_id uuid,
image_timestamp timestamp,
sort_number int,
image_id uuid,
-- Lots of other metadata fields here...
PRIMARY KEY(user_id, image_timestamp, sort_number)
)
WITH CLUSTERING ORDER BY(t ASC);
{noformat}
In practicality this is not really a big issue for us. We can just change the
column type from timeuuid to a uuid, and everything will behave the way that we
expect. While reading the code for gocql.UUIDFromTime() I also realize the our
implementation is broken, as the sequence number will wrap at times, since it's
only 14 bits long :)
> Wrong ordering for timeuuid fields
> --
>
> Key: CASSANDRA-15064
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15064
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Andreas Andersen
>Assignee: Jon Meredith
>Priority: Normal
> Attachments: example.cql
>
>
> Hi!
> We're seeing some strange behavior for the ordering of timeuuid fields. They
> seem to be sorted in the wrong order when the clock_seq_low field in a
> timeuuid goes from 7f to 80. Consider the following example:
> {noformat}
> cqlsh:test> show version;
> [cqlsh 5.0.1 | Cassandra 3.11.4 | CQL spec 3.4.4 | Native protocol v4]
> cqlsh:test> CREATE TABLE t (
> ... partition int,
> ... t timeuuid,
> ... i int,
> ...
> ... PRIMARY KEY(partition, t)
> ... )
> ... WITH CLUSTERING ORDER BY(t ASC);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b57e-f0def1d0755e, 1);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b57f-f0def1d0755e, 2);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b580-f0def1d0755e, 3);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b581-f0def1d0755e, 4);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b582-f0def1d0755e, 5);
> cqlsh:test> SELECT * FROM t WHERE partition = 1 ORDER BY t ASC;
>
> partition | t | i
> ---+--+---
> 1 | 84e2c963-4ef9-11e9-b580-f0def1d0755e | 3
> 1 | 84e2c963-4ef9-11e9-b581-f0def1d0755e | 4
> 1 |
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804977#comment-16804977 ] Patrick Bannister commented on CASSANDRA-10190: --- [~djoshi3] is working on moving the cqlshlib tests to the dtests in CASSANDRA-14990. On his suggestion, I'll build on his work. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- 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
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804971#comment-16804971 ] Patrick Bannister commented on CASSANDRA-10190: --- All of the cqlsh_tests dtests are passing again, time to look at the cqlshlib tests. Now we need to revisit the cqlshlib tests. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- 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
