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

mmh edited comment on CASSANDRA-13767 at 8/20/17 2:46 PM:
----------------------------------------------------------

where can i find the details about timestamps used in LWT/Paxos queries and 
"normal" queries?
The operation I posted in the issue is a simple way to reproduce the issue. In 
my real code, the insert  operation and the update operation belongs to two 
HTTP API, I first call the insert api, it takes about 20ms to complete, and 
then the update api is called. 
It is running in a test environment, both the client and cassandra server run 
on the same machine. So the timestamp should not be a problem, and the insert 
operation should have a timestamp earlier than the update operation by 20ms.

So, what's the detail of timestamps used in LWT/Paxos queries and "normal" 
queries?


was (Author: myrfy001):
where can i find the details about timestamps used in LWT/Paxos queries and 
"normal" queries?
The operation I posted in the issue is a simple way to reproduce the issue. In 
my real code, the insert  operation and the update operation belongs to two 
HTTP API, I first call the insert api, it takes about 20ms to complete, and 
then the update api
is called. 
It is running in a test environment, both the client and cassandra server run 
on the same machine. So the timestamp should not be a problem.

So, what's the detail of timestamps used in LWT/Paxos queries and "normal" 
queries?

> update a row which was inserted with 'IF NOT EXISTS' key word will fail 
> siently
> -------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-13767
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13767
>             Project: Cassandra
>          Issue Type: Bug
>          Components: CQL
>         Environment: [cqlsh 5.0.1 | Cassandra 3.11.0 | CQL spec 3.4.4 | 
> Native protocol v4]
> cassandra python driver = 3.5.0
> Run in dcoker with the following:
> docker run --name cassandra -v /data/cassandra:/var/lib/cassandra    
> -p9042:9042 -p9160:9160 -p7000:7000 -p7001:7001  cassandra
>            Reporter: mmh
>            Priority: Minor
>             Fix For: 3.11.0
>
>
> First, create keyspace and a table using the following
> {code:java}
> CREATE KEYSPACE scheduler WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'}  AND durable_writes = true;
> CREATE TABLE scheduler.job_info (
>     id timeuuid PRIMARY KEY,
>     create_time int,
>     cur_retry int,
>     cur_run_times int,
>     expire_time int,
>     max_retry int,
>     max_run_times int,
>     payload text,
>     period int,
>     retry_interval int,
>     status tinyint,
>     topic text,
>     type text,
>     update_time int
> ) with caching = {'keys':'ALL', 'rows_per_partition':'NONE'};
> {code}
> then, execute the following cql:
> {code:java}
> insert into job_info (id, create_time) values 
> (5be224c6-8231-11e7-9619-9801a7a97471, 0) IF NOT EXISTS;
> insert into job_info (id, create_time) values 
> (5be224c6-8231-11e7-9619-9801a7a97471, 1);
> select * from job_info;
> {code}
> You will find that create_time is still 0, it is not updated.
> but, if you remove the IF NOT EXISTS keyword in the first cql, the update 
> will success.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to