You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jeff Jirsa (JIRA)" <ji...@apache.org> on 2019/06/28 03:53:00 UTC
[jira] [Updated] (CASSANDRA-15187) Cann't table and materialized
view's timestamp column order by function well?
[ https://issues.apache.org/jira/browse/CASSANDRA-15187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeff Jirsa updated CASSANDRA-15187:
-----------------------------------
Resolution: Not A Bug
Status: Resolved (was: Triage Needed)
The clustering order by in the schema specifies the order of rows +within a partition+.
In your example, you're querying without a partition key in the WHERE , so +there's no ordering expected across partition keys+, and the results +ARE sorted as expected+ in the rows where there are multiple rows per partition.
> Cann't table and materialized view's timestamp column order by function well?
> ------------------------------------------------------------------------------
>
> Key: CASSANDRA-15187
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15187
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
> Reporter: gloCalHelp.com
> Priority: Normal
>
> Cann't table and materialized view's timestamp column order by function well?
> I am using cassandra3.11.3 on centos6.9 with python2.7.13, when I create a table as below:
> CREATE TABLE hygl_jcsj.hyjg_ods_yy_gps_novar4 (
> clcph text,
> dwsj timestamp,
> bc decimal,
> blbs decimal,
> cjbzh text,
> ckryid decimal,
> clid decimal,
> clmc text,
> ddfx decimal,
> ddrq timestamp,
> ddsj text,
> dlzbs decimal,
> dwrq timestamp,
> dwsk text,
> fcsxh decimal,
> fwj decimal,
> gd decimal,
> gdjd decimal,
> gdwd decimal,
> jd decimal,
> jsdlc decimal,
> jszjl decimal,
> jxzjl decimal,
> kxbs decimal,
> sfaxlxs decimal,
> sfcs decimal,
> sjgxsj timestamp,
> sjid text,
> sjlx decimal,
> sjlyxt decimal,
> sjsfzh text,
> sjwtid text,
> sjxm text,
> sjzlfj decimal,
> sssd decimal,
> szzdid decimal,
> szzdmc text,
> szzdxh decimal,
> wd decimal,
> xlbm text,
> xlid decimal,
> xlmc text,
> xslc decimal,
> xxfssj timestamp,
> xxjssj timestamp,
> xxrksj timestamp,
> xzzdid decimal,
> xzzdmc text,
> xzzdxh decimal,
> yxfx decimal,
> yygpsxxjlid decimal,
> yyzt decimal,
> PRIMARY KEY (clcph, dwsj)
> ) WITH CLUSTERING ORDER BY (dwsj ASC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = \{'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = 'GPS数据'
> AND compaction = \{'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = \{'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.0
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 3600000
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> the column dwsj is order by nature order of ASC, but when I use cqlsh -e "select clcph,dwsj from hygl_jcsj.hyjg_ods_yy_gps_novar4 limit 18",
> the result is:
> | clcph \| dwsj| | | | |
> |-----------------+---------------------------------| | | | |
> | a85161782800835 \| 2019-06-27 11:39:42.000000+0000| | | | |
> | a85161785390963 \| 2019-06-27 13:06:54.000000+0000| | | | |
> | a8516178847003 \| 2019-06-25 10:51:18.000000+0000| | | | |
> | a8516178847003 \| 2019-06-27 10:06:56.000000+0000| | | | |
> | a85161785095735 \| 2019-06-27 12:55:55.000000+0000| | | | |
> | a85161783068534 \| 2019-06-27 11:48:24.000000+0000| | | | |
> | a8516178475869 \| 2019-06-25 10:51:18.000000+0000| | | | |
> | a8516178475869 \| 2019-06-27 09:53:04.000000+0000| | | | |
> | a85161781283975 \| 2019-06-27 10:23:22.000000+0000| | | | |
> | a8516178463883 \| 2019-06-25 10:51:18.000000+0000| | | | |
> | a8516178463883 \| 2019-06-27 09:52:35.000000+0000| | | | |
> | a85161781409966 \| 2019-06-27 10:28:02.000000+0000| | | | |
> | a85161782554262 \| 2019-06-27 11:31:15.000000+0000| | | | |
> | a85161781705172 \| 2019-06-27 10:39:10.000000+0000| | | | |
> | a85161783259556 \| 2019-06-27 11:54:58.000000+0000| | | | |
> | a85161784046781 \| 2019-06-27 12:21:18.000000+0000| | | | |
> | a85161784825634 \| 2019-06-27 12:47:08.000000+0000| | | | |
> | a85161784662882 \| 2019-06-27 12:41:47.000000+0000| | | | |
>
> it is obvious a but that the dwsj column aren't order by ASC, how about the reverse order? then I create a materialzed view as this:
> create MATERIALIZED VIEW hygl_jcsj.MViewlastInsert_GPS4 AS
> select clcph, dwsj from hygl_jcsj.hyjg_ods_yy_gps_novar4 where clcph IS NOT NULL and dwsj IS NOT NULL
> PRIMARY KEY (clcph, dwsj)
> WITH CLUSTERING ORDER BY (dwsj DESC);
> but when I run the sql: -e "select * from hygl_jcsj.MViewlastInsert_GPS4 limit 18;"
> the result is
> | clcph \| dwsj| | | | |
> |-----------------+---------------------------------| | | | |
> | a85161782800835 \| 2019-06-27 11:39:42.000000+0000 | | | | |
> | a85161785390963 \| 2019-06-27 13:06:54.000000+0000 | | | | |
> | a8516178847003 \| 2019-06-27 10:06:56.000000+0000 | | | | |
> | a8516178847003 \| 2019-06-25 10:51:18.000000+0000 | | | | |
> | a85161785095735 \| 2019-06-27 12:55:55.000000+0000 | | | | |
> | a85161783068534 \| 2019-06-27 11:48:24.000000+0000 | | | | |
> | a8516178475869 \| 2019-06-27 09:53:04.000000+0000 | | | | |
> | a8516178475869 \| 2019-06-25 10:51:18.000000+0000 | | | | |
> | a85161781283975 \| 2019-06-27 10:23:22.000000+0000 | | | | |
> | a8516178463883 \| 2019-06-27 09:52:35.000000+0000 | | | | |
> | a8516178463883 \| 2019-06-25 10:51:18.000000+0000 | | | | |
> | a85161781409966 \| 2019-06-27 10:28:02.000000+0000 | | | | |
> | a85161782554262 \| 2019-06-27 11:31:15.000000+0000 | | | | |
> | a85161781705172 \| 2019-06-27 10:39:10.000000+0000 | | | | |
> | a85161783259556 \| 2019-06-27 11:54:58.000000+0000 | | | | |
> | a85161784046781 \| 2019-06-27 12:21:18.000000+0000 | | | | |
> | a85161784825634 \| 2019-06-27 12:47:08.000000+0000 | | | | |
> | a85161784662882 \| 2019-06-27 12:41:47.000000+0000 | | | |
>
>
> |
> It is obvious also a bug that the dwsj column aren't order by desc.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org