You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "gloCalHelp.com (JIRA)" <ji...@apache.org> on 2019/06/28 03:31:00 UTC
[jira] [Created] (CASSANDRA-15187) Cann't table and materialized
view's timestamp column order by function well?
gloCalHelp.com created CASSANDRA-15187:
------------------------------------------
Summary: 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
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