cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Stepura (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-7800) Incomplete results when selecting a particular column in the opposite order of my clustering
Date Tue, 19 Aug 2014 23:23:19 GMT

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

Mikhail Stepura updated CASSANDRA-7800:
---------------------------------------

    Description: 
When I run the following query, I get 96 rows back:

{code}
SELECT * FROM "DeviceCounterMonth" WHERE "counterGuid" = 3ae09592-91b3-568f-93d0-d7a77d46d2d7
AND "deviceGuid" = ae2fc84d-b85b-4fcf-9881-71af4cc5419d AND "startOfMonthLocal" = '2014-08-01T00:00:00+00:00'
ORDER BY "sampleBucketTimeLocal" DESC;
{code}

However, If I change DESC to ASC, I only get back a single row. In that row, {{sampleBucketTimeLocal}}
is {{null}}, which is not true of any of the rows returned by the first query, and should
be impossible since it's part of the primary key.

Further, if I select specific columns (instead of *), as long as I leave out tenantGuid, the
query returns the same expected 96 rows regardless of whether I use DESC or ASC.

I haven't been able to create a minimal repro, so I'm attaching a dump of the table. The schema
is as follows:
{code}
CREATE TABLE "DeviceCounterMonth" (
  "counterGuid" uuid,
  "deviceGuid" uuid,
  "startOfMonthLocal" text,
  "sampleBucketTimeLocal" text,
  max float,
  mean float,
  min float,
  samples bigint,
  "stdDevs" float,
  "tenantGuid" uuid,
  PRIMARY KEY (("counterGuid", "deviceGuid", "startOfMonthLocal"), "sampleBucketTimeLocal")
) WITH CLUSTERING ORDER BY ("sampleBucketTimeLocal" DESC) AND
  bloom_filter_fp_chance=0.010000 AND
  caching='KEYS_ONLY' AND
  comment='' AND
  dclocal_read_repair_chance=0.000000 AND
  gc_grace_seconds=864000 AND
  index_interval=128 AND
  read_repair_chance=0.100000 AND
  populate_io_cache_on_flush='false' AND
  default_time_to_live=0 AND
  speculative_retry='99.0PERCENTILE' AND
  memtable_flush_period_in_ms=0 AND
  compaction={'class': 'SizeTieredCompactionStrategy'} AND
  compression={'sstable_compression': 'LZ4Compressor'};
{code}

  was:
When I run the following query, I get 96 rows back:

SELECT * FROM "DeviceCounterMonth" WHERE "counterGuid" = 3ae09592-91b3-568f-93d0-d7a77d46d2d7
AND "deviceGuid" = ae2fc84d-b85b-4fcf-9881-71af4cc5419d AND "startOfMonthLocal" = '2014-08-01T00:00:00+00:00'
ORDER BY "sampleBucketTimeLocal" DESC;

However, If I change DESC to ASC, I only get back a single row. In that row, sampleBucketTimeLocal
is null, which is not true of any of the rows returned by the first query, and should be impossible
since it's part of the primary key.

Further, if I select specific columns (instead of *), as long as I leave out tenantGuid, the
query returns the same expected 96 rows regardless of whether I use DESC or ASC.

I haven't been able to create a minimal repro, so I'm attaching a dump of the table. The schema
is as follows:
CREATE TABLE "DeviceCounterMonth" (
  "counterGuid" uuid,
  "deviceGuid" uuid,
  "startOfMonthLocal" text,
  "sampleBucketTimeLocal" text,
  max float,
  mean float,
  min float,
  samples bigint,
  "stdDevs" float,
  "tenantGuid" uuid,
  PRIMARY KEY (("counterGuid", "deviceGuid", "startOfMonthLocal"), "sampleBucketTimeLocal")
) WITH CLUSTERING ORDER BY ("sampleBucketTimeLocal" DESC) AND
  bloom_filter_fp_chance=0.010000 AND
  caching='KEYS_ONLY' AND
  comment='' AND
  dclocal_read_repair_chance=0.000000 AND
  gc_grace_seconds=864000 AND
  index_interval=128 AND
  read_repair_chance=0.100000 AND
  populate_io_cache_on_flush='false' AND
  default_time_to_live=0 AND
  speculative_retry='99.0PERCENTILE' AND
  memtable_flush_period_in_ms=0 AND
  compaction={'class': 'SizeTieredCompactionStrategy'} AND
  compression={'sstable_compression': 'LZ4Compressor'};


> Incomplete results when selecting a particular column in the opposite order of my clustering
> --------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-7800
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7800
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: cqlsh 4.1.1 | Cassandra 2.0.8 | CQL spec 3.1.1 | Thrift protocol
19.39.0
>            Reporter: Cody Rank
>         Attachments: dcm.txt
>
>
> When I run the following query, I get 96 rows back:
> {code}
> SELECT * FROM "DeviceCounterMonth" WHERE "counterGuid" = 3ae09592-91b3-568f-93d0-d7a77d46d2d7
AND "deviceGuid" = ae2fc84d-b85b-4fcf-9881-71af4cc5419d AND "startOfMonthLocal" = '2014-08-01T00:00:00+00:00'
ORDER BY "sampleBucketTimeLocal" DESC;
> {code}
> However, If I change DESC to ASC, I only get back a single row. In that row, {{sampleBucketTimeLocal}}
is {{null}}, which is not true of any of the rows returned by the first query, and should
be impossible since it's part of the primary key.
> Further, if I select specific columns (instead of *), as long as I leave out tenantGuid,
the query returns the same expected 96 rows regardless of whether I use DESC or ASC.
> I haven't been able to create a minimal repro, so I'm attaching a dump of the table.
The schema is as follows:
> {code}
> CREATE TABLE "DeviceCounterMonth" (
>   "counterGuid" uuid,
>   "deviceGuid" uuid,
>   "startOfMonthLocal" text,
>   "sampleBucketTimeLocal" text,
>   max float,
>   mean float,
>   min float,
>   samples bigint,
>   "stdDevs" float,
>   "tenantGuid" uuid,
>   PRIMARY KEY (("counterGuid", "deviceGuid", "startOfMonthLocal"), "sampleBucketTimeLocal")
> ) WITH CLUSTERING ORDER BY ("sampleBucketTimeLocal" DESC) AND
>   bloom_filter_fp_chance=0.010000 AND
>   caching='KEYS_ONLY' AND
>   comment='' AND
>   dclocal_read_repair_chance=0.000000 AND
>   gc_grace_seconds=864000 AND
>   index_interval=128 AND
>   read_repair_chance=0.100000 AND
>   populate_io_cache_on_flush='false' AND
>   default_time_to_live=0 AND
>   speculative_retry='99.0PERCENTILE' AND
>   memtable_flush_period_in_ms=0 AND
>   compaction={'class': 'SizeTieredCompactionStrategy'} AND
>   compression={'sstable_compression': 'LZ4Compressor'};
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message