[ https://issues.apache.org/jira/browse/CASSANDRA-10428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093084#comment-15093084 ]
Paulo Motta edited comment on CASSANDRA-10428 at 1/12/16 2:02 AM: ------------------------------------------------------------------ Overall code and tests looks good. Some minor observations: * Using your [example|https://issues.apache.org/jira/browse/CASSANDRA-10428?focusedCommentId=14939157&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14939157], the following works: {noformat} cqlsh:ks> SELECT * from test where id='1' and time = '2015-09-29 20:54:24.200'; id | time | val ----+---------------------------------+----- 1 | 2015-09-29 23:54:24.200000+0000 | abc {noformat} but the following does not work: {noformat} cqlsh:ks> SELECT * from test where id='1' and time = '2015-09-29 20:54:24.20'; id | time | val ----+------+----- (0 rows) {noformat} What would be the correct behavior in this case? * Surprisingly this didn't break (m)any [cqlsh dtests|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10428-dtest/4/testReport/], is this expected? * It seems the {{%f}} format does not work correctly on jython on Windows, according to this [stack overflow answer|http://stackoverflow.com/a/17270917/5477191]. I wonder if we should also support this on non-standard python implementations. -I will test with standard python on Windows and see if it works.- Tested on standard python on Windows and worked correctly. * I tested with copy to/from, and it seems to work correctly, but microseconds are silently discarded on copy from since we don't support this natively in the timestamp format. Should we maybe print a warning if the timestamp is in sub-ms precision different from zero? was (Author: pauloricardomg): Overall code and tests looks good. Some minor observations: * Using your [example|https://issues.apache.org/jira/browse/CASSANDRA-10428?focusedCommentId=14939157&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14939157], the following works: {noformat} cqlsh:ks> SELECT * from test where id='1' and time = '2015-09-29 20:54:24.200'; id | time | val ----+---------------------------------+----- 1 | 2015-09-29 23:54:24.200000+0000 | abc {noformat} but the following does not work: {noformat} cqlsh:ks> SELECT * from test where id='1' and time = '2015-09-29 20:54:24.20'; id | time | val ----+------+----- (0 rows) {noformat} What would be the correct behavior in this case? * Surprisingly this didn't break (m)any [cqlsh dtests|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10428-dtest/4/testReport/], is this expected? * It seems the {{%f}} format does not work correctly on jython on Windows, according to this [stack overflow answer|http://stackoverflow.com/a/17270917/5477191]. I wonder if we should also support this on non-standard python implementations. I will test with standard python on Windows and see if it works. * I tested with copy to/from, and it seems to work correctly, but microseconds are silently discarded on copy from since we don't support this natively in the timestamp format. Should we maybe print a warning if the timestamp is in sub-ms precision different from zero? > cqlsh: Include sub-second precision in timestamps by default > ------------------------------------------------------------ > > Key: CASSANDRA-10428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10428 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: OSX 10.10.2 > Reporter: Chandran Anjur Narasimhan > Assignee: Stefania > Labels: cqlsh > Fix For: 3.x > > > Query with >= timestamp works. But the exact timestamp value is not working. > {noformat} > NCHAN-M-D0LZ:bin nchan$ ./cqlsh > Connected to CCC Multi-Region Cassandra Cluster at <host>:<port>. > [cqlsh 5.0.1 | Cassandra 2.1.7 | CQL spec 3.2.0 | Native protocol v3] > Use HELP for help. > cqlsh> > {noformat} > {panel:title=Schema|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE} > cqlsh:ccc> desc COLUMNFAMILY ez_task_result ; > CREATE TABLE ccc.ez_task_result ( > submissionid text, > ezid text, > name text, > time timestamp, > analyzed_index_root text, > ... > ... > PRIMARY KEY (submissionid, ezid, name, time) > {panel} > {panel:title=Working|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE} > cqlsh:ccc> select submissionid, ezid, name, time, state, status, > translated_criteria_status from ez_task_result where > submissionid='760dd154670811e58c04005056bb6ff0' and > ezid='760dd6de670811e594fc005056bb6ff0' and name='run-sanities' and > time>='2015-09-29 20:54:23-0700'; > submissionid | ezid | name > | time | state | status | > translated_criteria_status > ----------------------------------+----------------------------------+--------------+--------------------------+-----------+-------------+---------------------------- > 760dd154670811e58c04005056bb6ff0 | 760dd6de670811e594fc005056bb6ff0 | > run-sanities | 2015-09-29 20:54:23-0700 | EXECUTING | IN_PROGRESS | > run-sanities started > (1 rows) > cqlsh:ccc> > {panel} > {panel:title=Not > working|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE} > cqlsh:ccc> select submissionid, ezid, name, time, state, status, > translated_criteria_status from ez_task_result where > submissionid='760dd154670811e58c04005056bb6ff0' and > ezid='760dd6de670811e594fc005056bb6ff0' and name='run-sanities' and > time='2015-09-29 20:54:23-0700'; > submissionid | ezid | name | time | analyzed_index_root | analyzed_log_path > | clientid | end_time | jenkins_path | log_file_path | path_available | > path_to_task | required_for_overall_status | start_time | state | status | > translated_criteria_status | type > --------------+------+------+------+---------------------+-------------------+----------+----------+--------------+---------------+----------------+--------------+-----------------------------+------------+-------+--------+----------------------------+------ > (0 rows) > cqlsh:ccc> > {panel} -- This message was sent by Atlassian JIRA (v6.3.4#6332)