[jira] [Commented] (CASSANDRA-6147) Break timestamp ties for thrift-ers
[ https://issues.apache.org/jira/browse/CASSANDRA-6147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920986#comment-13920986 ] Nate McCall commented on CASSANDRA-6147: That would actually be very helpful and would not break anything in the wild (Astyanax, Hector and (im pretty sure) pycassa all assert a not-null timestamp on egress anyhoo), so it would be unusual for someone to be relying on this as validation currently. Break timestamp ties for thrift-ers --- Key: CASSANDRA-6147 URL: https://issues.apache.org/jira/browse/CASSANDRA-6147 Project: Cassandra Issue Type: Sub-task Reporter: Edward Capriolo Assignee: Edward Capriolo Fix For: 2.1 beta2 Thrift users are still forced to generate timestamps on the client side. Currently the way the thrift bindings are generated users are forced to supply timestamps. There are two solutions I see. * -1 as timestamp means generate on the server side This is a breaking change, for those using -1 as a timestamp (which should effectively be no one. * Prepare yourself Our thrift signatures are wrong, you can't overload methods in thrift thrift.get(byte [], byte[], ts) should REALLY be changed to GetRequest g = new GetRequest() g.setName() g.setValue() g.setTs() ///optional thrift. get( g ) I know no one is going to want to make this change because thrift is quasi/dead but it would allow us to evolve thrift in a meaningful way. We could simple add these new methods under different names as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6147) Break timestamp ties for thrift-ers
[ https://issues.apache.org/jira/browse/CASSANDRA-6147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13921007#comment-13921007 ] Edward Capriolo commented on CASSANDRA-6147: I do not think this would break anything. Anything currently out there must be setting the timestamp explicitly. Anything not setting the timestamp is just getting 0. Users quickly find out what happens when two inserts have the same 0 timestamp Break timestamp ties for thrift-ers --- Key: CASSANDRA-6147 URL: https://issues.apache.org/jira/browse/CASSANDRA-6147 Project: Cassandra Issue Type: Sub-task Reporter: Edward Capriolo Assignee: Edward Capriolo Fix For: 2.1 beta2 Thrift users are still forced to generate timestamps on the client side. Currently the way the thrift bindings are generated users are forced to supply timestamps. There are two solutions I see. * -1 as timestamp means generate on the server side This is a breaking change, for those using -1 as a timestamp (which should effectively be no one. * Prepare yourself Our thrift signatures are wrong, you can't overload methods in thrift thrift.get(byte [], byte[], ts) should REALLY be changed to GetRequest g = new GetRequest() g.setName() g.setValue() g.setTs() ///optional thrift. get( g ) I know no one is going to want to make this change because thrift is quasi/dead but it would allow us to evolve thrift in a meaningful way. We could simple add these new methods under different names as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6147) Break timestamp ties for thrift-ers
[ https://issues.apache.org/jira/browse/CASSANDRA-6147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13921018#comment-13921018 ] Jonathan Ellis commented on CASSANDRA-6147: --- I'm a little confused, are we changing scope on this ticket from break timestamp ties to allow opting in to server-side timestamps? nanotime is basically random so that would break ties but not very usefully :) Break timestamp ties for thrift-ers --- Key: CASSANDRA-6147 URL: https://issues.apache.org/jira/browse/CASSANDRA-6147 Project: Cassandra Issue Type: Sub-task Reporter: Edward Capriolo Assignee: Edward Capriolo Fix For: 2.1 beta2 Thrift users are still forced to generate timestamps on the client side. Currently the way the thrift bindings are generated users are forced to supply timestamps. There are two solutions I see. * -1 as timestamp means generate on the server side This is a breaking change, for those using -1 as a timestamp (which should effectively be no one. * Prepare yourself Our thrift signatures are wrong, you can't overload methods in thrift thrift.get(byte [], byte[], ts) should REALLY be changed to GetRequest g = new GetRequest() g.setName() g.setValue() g.setTs() ///optional thrift. get( g ) I know no one is going to want to make this change because thrift is quasi/dead but it would allow us to evolve thrift in a meaningful way. We could simple add these new methods under different names as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6147) Break timestamp ties for thrift-ers
[ https://issues.apache.org/jira/browse/CASSANDRA-6147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13921033#comment-13921033 ] Edward Capriolo commented on CASSANDRA-6147: [~jbellis] You are right I kinda stole this ticket. The point of this patch is that if CQL can auto-timestamp things, thrift should be able to as well. Would you like me to open another ticket? Should the auto-timestamp be system.currentTimeMillis() + 1000? How does CQL arrive at its auto timestamp? Break timestamp ties for thrift-ers --- Key: CASSANDRA-6147 URL: https://issues.apache.org/jira/browse/CASSANDRA-6147 Project: Cassandra Issue Type: Sub-task Reporter: Edward Capriolo Assignee: Edward Capriolo Fix For: 2.1 beta2 Thrift users are still forced to generate timestamps on the client side. Currently the way the thrift bindings are generated users are forced to supply timestamps. There are two solutions I see. * -1 as timestamp means generate on the server side This is a breaking change, for those using -1 as a timestamp (which should effectively be no one. * Prepare yourself Our thrift signatures are wrong, you can't overload methods in thrift thrift.get(byte [], byte[], ts) should REALLY be changed to GetRequest g = new GetRequest() g.setName() g.setValue() g.setTs() ///optional thrift. get( g ) I know no one is going to want to make this change because thrift is quasi/dead but it would allow us to evolve thrift in a meaningful way. We could simple add these new methods under different names as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6147) Break timestamp ties for thrift-ers
[
https://issues.apache.org/jira/browse/CASSANDRA-6147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919523#comment-13919523
]
Edward Capriolo commented on CASSANDRA-6147:
{code}
struct Column {
1: required binary name,
2: optional binary value,
3: optional i64 timestamp,
4: optional i32 ttl,
}
{code}
In thrift timestamps are optional, but the CassandraServer rejects Columns
without a timestmap
This is a rather easy patch.
{code}
if (!column.isSetTimestamp())
-throw new
org.apache.cassandra.exceptions.InvalidRequestException(Column timestamp is
required);
-
+column.setTimestamp(System.nanoTime());
{code}
https://github.com/edwardcapriolo/cassandra/compare/aut0-timstamps-thrift?expand=1
Break timestamp ties for thrift-ers
---
Key: CASSANDRA-6147
URL: https://issues.apache.org/jira/browse/CASSANDRA-6147
Project: Cassandra
Issue Type: Sub-task
Reporter: Edward Capriolo
Assignee: Edward Capriolo
Fix For: 2.1 beta2
Thrift users are still forced to generate timestamps on the client side.
Currently the way the thrift bindings are generated users are forced to
supply timestamps. There are two solutions I see.
* -1 as timestamp means generate on the server side
This is a breaking change, for those using -1 as a timestamp (which should
effectively be no one.
* Prepare yourself
Our thrift signatures are wrong, you can't overload methods in thrift
thrift.get(byte [], byte[], ts)
should REALLY be changed to
GetRequest g = new GetRequest()
g.setName()
g.setValue()
g.setTs() ///optional
thrift. get( g )
I know no one is going to want to make this change because thrift is
quasi/dead but it would allow us to evolve thrift in a meaningful way. We
could simple add these new methods under different names as well.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-6147) Break timestamp ties for thrift-ers
[ https://issues.apache.org/jira/browse/CASSANDRA-6147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13791276#comment-13791276 ] Ramon Nogueira commented on CASSANDRA-6147: --- This is not really a solution that allows you to use client-generated timestamps and get row-level isolation (the real problem). Instead what you are providing is a way to opt-out of client generated timestamps altogether. But client-generated timestamps still break row-isolation, and this affects CQL too. Break timestamp ties for thrift-ers --- Key: CASSANDRA-6147 URL: https://issues.apache.org/jira/browse/CASSANDRA-6147 Project: Cassandra Issue Type: Sub-task Reporter: Edward Capriolo Assignee: Edward Capriolo Fix For: 2.1 Thrift users are still forced to generate timestamps on the client side. Currently the way the thrift bindings are generated users are forced to supply timestamps. There are two solutions I see. * -1 as timestamp means generate on the server side This is a breaking change, for those using -1 as a timestamp (which should effectively be no one. * Prepare yourself Our thrift signatures are wrong, you can't overload methods in thrift thrift.get(byte [], byte[], ts) should REALLY be changed to GetRequest g = new GetRequest() g.setName() g.setValue() g.setTs() ///optional thrift. get( g ) I know no one is going to want to make this change because thrift is quasi/dead but it would allow us to evolve thrift in a meaningful way. We could simple add these new methods under different names as well. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6147) Break timestamp ties for thrift-ers
[ https://issues.apache.org/jira/browse/CASSANDRA-6147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13791534#comment-13791534 ] Edward Capriolo commented on CASSANDRA-6147: I see. Just not having to generate the timestamps would be useful anyway. Break timestamp ties for thrift-ers --- Key: CASSANDRA-6147 URL: https://issues.apache.org/jira/browse/CASSANDRA-6147 Project: Cassandra Issue Type: Sub-task Reporter: Edward Capriolo Assignee: Edward Capriolo Fix For: 2.1 Thrift users are still forced to generate timestamps on the client side. Currently the way the thrift bindings are generated users are forced to supply timestamps. There are two solutions I see. * -1 as timestamp means generate on the server side This is a breaking change, for those using -1 as a timestamp (which should effectively be no one. * Prepare yourself Our thrift signatures are wrong, you can't overload methods in thrift thrift.get(byte [], byte[], ts) should REALLY be changed to GetRequest g = new GetRequest() g.setName() g.setValue() g.setTs() ///optional thrift. get( g ) I know no one is going to want to make this change because thrift is quasi/dead but it would allow us to evolve thrift in a meaningful way. We could simple add these new methods under different names as well. -- This message was sent by Atlassian JIRA (v6.1#6144)
