[ 
https://issues.apache.org/jira/browse/CASSANDRA-10428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15094141#comment-15094141
 ] 

Stefania commented on CASSANDRA-10428:
--------------------------------------

bq. {{SELECT * from test where id='1' and time = '2015-09-29 20:54:24.20';}} 
does not work...

{{cqlsh}} sends text statements to the server so the problem is server side, 
have a look at {{dateStringPatterns}} in TimestampSerializer.java. Due to the 
multiplication of time format combinations with the time zone and so forth, 
we'd have to add several patterns to support fewer millisecond digits. A 
regular expression would perhaps be better. Either way it's not a trivial 
change and I would prefer to open a different ticket since it is not related to 
cqlsh.

bq. Surprisingly this didn't break (m)any cqlsh dtests, is this expected?

If we are still referring to the point above, I would assume that yes it is 
expected since it is something we currently do not support server side.

bq. It seems the %f format does not work correctly on jython on Windows,

This would explain the {{%f}} noted above that I could not reproduce. I'm not 
sure if we need to support the lack of {{%f}} for jython on Windows, cc 
[~thobbs]. If we do, how would we recognize that we are running on jython? 

Thanks for testing on Windows and for working out the {{%f}} problem!

bq. 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?

We cannot print warnings in the worker processes at present. We can return 
errors to the parent process, but this would be excessive, or we have a limited 
{{printdebug}} method that only works with {{cqlsh --debug}} and does not take 
into account the fact that we may want to suppress warnings when printing to 
STDOUT as we do in the parent process. To support warnings properly, we need to 
extend the communication protocol between parent and worker processes. Also, in 
case of an exact string format match, it is not easy to recognize 
sub-milliseconds,  so I would prefer to leave it as is. I don't think the extra 
work would be justified. I have however added a new test, 
{{test_round_trip_with_sub_second_precision}}.

I've rebased and restarted CI.

> 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)

Reply via email to