[jira] [Updated] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[
https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-7304:
-
Labels: client-impacting cql protocolv4 (was: cql protocolv4)
Ability to distinguish between NULL and UNSET values in Prepared Statements
---
Key: CASSANDRA-7304
URL: https://issues.apache.org/jira/browse/CASSANDRA-7304
Project: Cassandra
Issue Type: Sub-task
Reporter: Drew Kutcharian
Assignee: Oded Peer
Labels: client-impacting, cql, protocolv4
Fix For: 2.2.0 beta 1
Attachments: 7304-03.patch, 7304-04.patch, 7304-05.patch,
7304-06.patch, 7304-07.patch, 7304-2.patch, 7304-V8.txt, 7304.patch
Currently Cassandra inserts tombstones when a value of a column is bound to
NULL in a prepared statement. At higher insert rates managing all these
tombstones becomes an unnecessary overhead. This limits the usefulness of the
prepared statements since developers have to either create multiple prepared
statements (each with a different combination of column names, which at times
is just unfeasible because of the sheer number of possible combinations) or
fall back to using regular (non-prepared) statements.
This JIRA is here to explore the possibility of either:
A. Have a flag on prepared statements that once set, tells Cassandra to
ignore null columns
or
B. Have an UNSET value which makes Cassandra skip the null columns and not
tombstone them
Basically, in the context of a prepared statement, a null value means delete,
but we don’t have anything that means ignore (besides creating a new
prepared statement without the ignored column).
Please refer to the original conversation on DataStax Java Driver mailing
list for more background:
https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion
*EDIT 18/12/14 - [~odpeer] Implementation Notes:*
The motivation hasn't changed.
Protocol version 4 specifies that bind variables do not require having a
value when executing a statement. Bind variables without a value are called
'unset'. The 'unset' bind variable is serialized as the int value '-2'
without following bytes.
\\
\\
* An unset bind variable in an EXECUTE or BATCH request
** On a {{value}} does not modify the value and does not create a tombstone
** On the {{ttl}} clause is treated as 'unlimited'
** On the {{timestamp}} clause is treated as 'now'
** On a map key or a list index throws {{InvalidRequestException}}
** On a {{counter}} increment or decrement operation does not change the
counter value, e.g. {{UPDATE my_tab SET c = c - ? WHERE k = 1}} does change
the value of counter {{c}}
** On a tuple field or UDT field throws {{InvalidRequestException}}
* An unset bind variable in a QUERY request
** On a partition column, clustering column or index column in the {{WHERE}}
clause throws {{InvalidRequestException}}
** On the {{limit}} clause is treated as 'unlimited'
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[
https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-7304:
--
Attachment: 7304-V8.txt
+1
Thanks for the patch [~odpeer].
I rebased it and corrected a few remaining nits.
Ability to distinguish between NULL and UNSET values in Prepared Statements
---
Key: CASSANDRA-7304
URL: https://issues.apache.org/jira/browse/CASSANDRA-7304
Project: Cassandra
Issue Type: Sub-task
Reporter: Drew Kutcharian
Assignee: Oded Peer
Labels: cql, protocolv4
Fix For: 3.0
Attachments: 7304-03.patch, 7304-04.patch, 7304-05.patch,
7304-06.patch, 7304-07.patch, 7304-2.patch, 7304-V8.txt, 7304.patch
Currently Cassandra inserts tombstones when a value of a column is bound to
NULL in a prepared statement. At higher insert rates managing all these
tombstones becomes an unnecessary overhead. This limits the usefulness of the
prepared statements since developers have to either create multiple prepared
statements (each with a different combination of column names, which at times
is just unfeasible because of the sheer number of possible combinations) or
fall back to using regular (non-prepared) statements.
This JIRA is here to explore the possibility of either:
A. Have a flag on prepared statements that once set, tells Cassandra to
ignore null columns
or
B. Have an UNSET value which makes Cassandra skip the null columns and not
tombstone them
Basically, in the context of a prepared statement, a null value means delete,
but we don’t have anything that means ignore (besides creating a new
prepared statement without the ignored column).
Please refer to the original conversation on DataStax Java Driver mailing
list for more background:
https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion
*EDIT 18/12/14 - [~odpeer] Implementation Notes:*
The motivation hasn't changed.
Protocol version 4 specifies that bind variables do not require having a
value when executing a statement. Bind variables without a value are called
'unset'. The 'unset' bind variable is serialized as the int value '-2'
without following bytes.
\\
\\
* An unset bind variable in an EXECUTE or BATCH request
** On a {{value}} does not modify the value and does not create a tombstone
** On the {{ttl}} clause is treated as 'unlimited'
** On the {{timestamp}} clause is treated as 'now'
** On a map key or a list index throws {{InvalidRequestException}}
** On a {{counter}} increment or decrement operation does not change the
counter value, e.g. {{UPDATE my_tab SET c = c - ? WHERE k = 1}} does change
the value of counter {{c}}
** On a tuple field or UDT field throws {{InvalidRequestException}}
* An unset bind variable in a QUERY request
** On a partition column, clustering column or index column in the {{WHERE}}
clause throws {{InvalidRequestException}}
** On the {{limit}} clause is treated as 'unlimited'
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[
https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oded Peer updated CASSANDRA-7304:
-
Attachment: 7304-07.patch
Right. Fixed in 7304-07.patch
Ability to distinguish between NULL and UNSET values in Prepared Statements
---
Key: CASSANDRA-7304
URL: https://issues.apache.org/jira/browse/CASSANDRA-7304
Project: Cassandra
Issue Type: Sub-task
Reporter: Drew Kutcharian
Assignee: Oded Peer
Labels: cql, protocolv4
Fix For: 3.0
Attachments: 7304-03.patch, 7304-04.patch, 7304-05.patch,
7304-06.patch, 7304-07.patch, 7304-2.patch, 7304.patch
Currently Cassandra inserts tombstones when a value of a column is bound to
NULL in a prepared statement. At higher insert rates managing all these
tombstones becomes an unnecessary overhead. This limits the usefulness of the
prepared statements since developers have to either create multiple prepared
statements (each with a different combination of column names, which at times
is just unfeasible because of the sheer number of possible combinations) or
fall back to using regular (non-prepared) statements.
This JIRA is here to explore the possibility of either:
A. Have a flag on prepared statements that once set, tells Cassandra to
ignore null columns
or
B. Have an UNSET value which makes Cassandra skip the null columns and not
tombstone them
Basically, in the context of a prepared statement, a null value means delete,
but we don’t have anything that means ignore (besides creating a new
prepared statement without the ignored column).
Please refer to the original conversation on DataStax Java Driver mailing
list for more background:
https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion
*EDIT 18/12/14 - [~odpeer] Implementation Notes:*
The motivation hasn't changed.
Protocol version 4 specifies that bind variables do not require having a
value when executing a statement. Bind variables without a value are called
'unset'. The 'unset' bind variable is serialized as the int value '-2'
without following bytes.
\\
\\
* An unset bind variable in an EXECUTE or BATCH request
** On a {{value}} does not modify the value and does not create a tombstone
** On the {{ttl}} clause is treated as 'unlimited'
** On the {{timestamp}} clause is treated as 'now'
** On a map key or a list index throws {{InvalidRequestException}}
** On a {{counter}} increment or decrement operation does not change the
counter value, e.g. {{UPDATE my_tab SET c = c - ? WHERE k = 1}} does change
the value of counter {{c}}
** On a tuple field or UDT field throws {{InvalidRequestException}}
* An unset bind variable in a QUERY request
** On a partition column, clustering column or index column in the {{WHERE}}
clause throws {{InvalidRequestException}}
** On the {{limit}} clause is treated as 'unlimited'
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[
https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oded Peer updated CASSANDRA-7304:
-
Attachment: 7304-06.patch
Added a new patch 7304-06.patch
{quote}
There are a few use cases that are not tested and that seems to not work
properly:
List marker: SELECT * FROM %s WHERE k in ? or SELECT * FROM %s WHERE k = ? AND
i IN ?
{quote}
Fixed.
bq. Tuple marker: SELECT * FROM %s WHERE k = ? and (i, j) = ?
Fixed.
bq. Collection marker containing an unset value. For example: INSERT INTO %s
(k, m) VALUES (10, ?) where the value for the map m will be map(k, unset())
The value of the map entry can be an unset value only in testing and internal
code, It can't happen from client code.
unset variables only applies to bind variables in a CQL query. A CQL client
can not create an unset ByteBuffer as a map value since it is not a bound
value.
bq. Queries with CONTAINS or CONTAINS KEY conditions
Added tests.
{quote}
There is also a few use cases that are not tested and that I have not tried:
Secondary index queries on collection key or value with unset values
{quote}
Added tests.
bq. UPDATE or DELETE queries with unset values in the WHERE clause
Added tests.
{quote}
Nested tulpe with unset values
It looks like you missed the following remark from Sylvain
In ModificationStatement.executeInternal, the body of the for loop should just
be replaced by mutation.apply().
{quote}
I didn't replace the for loop body since the {{apply()}} method is not in the
{{IMutation}} interface.
The {{apply()}} method signature is different in {{Mutation}} and
{{CounterMutation}}, one is {{void}} while the other returns a {{Mutation}}
instance.
I chose to leave it as-is.
bq. I do not understand your change in FunctionCall. We cannot know if some
function can accept null or not as somebody can create a UDF for which null is
a valid input. For unset value, we need to block them in FunctionCall as the
existing functions will break otherwise.
Since functions do not accept bind variables as input, only column identifiers,
and A column value can not be an unset value.
I added a comment to {{FunctionCall}} stating why there is no need in checking
for unset variables in functions.
{quote}
The error messages for tuples and UDT do not provides enough information if you
have multiple of them in the query (e.g.
SELECT * FROM myTable WHERE a = 0 AND (b, c) = (?, ?) AND (d, e) (?, ?)).
I am not sure how we could provide a better message but you might be able to
find a way? At least for UDT we should provide the type name in the error
message.
{quote}
I added more information to the bind marker position, and added a test.
bq. In Sets.Adder.doAdd, Lists.Appender.doAppend and Maps.Appender.doAppend
there are some unused variable.
Done.
bq. In Sets, Lists, Maps and Constants there are several place where you use
some unecessary else. The if either end by a return or by throwing an Exception.
I think it's a matter of taste. I changed it and remvoed the unecessary else.
bq. I would be in favor to put the tests in the corresponding unit tests rather
than in a new one. For example I will put the collection tests in
CollectionsTest. I believe that it will help people if all the tests for a
collections for example are together. It can serve as a form of documentation.
Done. I moved tests to CollectionsTest, TupleTypeTest, UserTypesTest.
bq. You should add the feature to the News.txt
Done.
bq. There are still a lot of whitespaces in your patch.
Fixed.
Ability to distinguish between NULL and UNSET values in Prepared Statements
---
Key: CASSANDRA-7304
URL: https://issues.apache.org/jira/browse/CASSANDRA-7304
Project: Cassandra
Issue Type: Sub-task
Reporter: Drew Kutcharian
Assignee: Oded Peer
Labels: cql, protocolv4
Fix For: 3.0
Attachments: 7304-03.patch, 7304-04.patch, 7304-05.patch,
7304-06.patch, 7304-2.patch, 7304.patch
Currently Cassandra inserts tombstones when a value of a column is bound to
NULL in a prepared statement. At higher insert rates managing all these
tombstones becomes an unnecessary overhead. This limits the usefulness of the
prepared statements since developers have to either create multiple prepared
statements (each with a different combination of column names, which at times
is just unfeasible because of the sheer number of possible combinations) or
fall back to using regular (non-prepared) statements.
This JIRA is here to explore the possibility of either:
A. Have a flag on prepared statements that once set, tells Cassandra to
ignore null columns
or
B. Have an UNSET value which makes Cassandra skip the null columns and not
tombstone them
Basically, in the context
[jira] [Updated] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[
https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oded Peer updated CASSANDRA-7304:
-
Attachment: 7304-05.patch
Rebased to trunk
Ability to distinguish between NULL and UNSET values in Prepared Statements
---
Key: CASSANDRA-7304
URL: https://issues.apache.org/jira/browse/CASSANDRA-7304
Project: Cassandra
Issue Type: Sub-task
Reporter: Drew Kutcharian
Assignee: Oded Peer
Labels: cql, protocolv4
Fix For: 3.0
Attachments: 7304-03.patch, 7304-04.patch, 7304-05.patch,
7304-2.patch, 7304.patch
Currently Cassandra inserts tombstones when a value of a column is bound to
NULL in a prepared statement. At higher insert rates managing all these
tombstones becomes an unnecessary overhead. This limits the usefulness of the
prepared statements since developers have to either create multiple prepared
statements (each with a different combination of column names, which at times
is just unfeasible because of the sheer number of possible combinations) or
fall back to using regular (non-prepared) statements.
This JIRA is here to explore the possibility of either:
A. Have a flag on prepared statements that once set, tells Cassandra to
ignore null columns
or
B. Have an UNSET value which makes Cassandra skip the null columns and not
tombstone them
Basically, in the context of a prepared statement, a null value means delete,
but we don’t have anything that means ignore (besides creating a new
prepared statement without the ignored column).
Please refer to the original conversation on DataStax Java Driver mailing
list for more background:
https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion
*EDIT 18/12/14 - [~odpeer] Implementation Notes:*
The motivation hasn't changed.
Protocol version 4 specifies that bind variables do not require having a
value when executing a statement. Bind variables without a value are called
'unset'. The 'unset' bind variable is serialized as the int value '-2'
without following bytes.
\\
\\
* An unset bind variable in an EXECUTE or BATCH request
** On a {{value}} does not modify the value and does not create a tombstone
** On the {{ttl}} clause is treated as 'unlimited'
** On the {{timestamp}} clause is treated as 'now'
** On a map key or a list index throws {{InvalidRequestException}}
** On a {{counter}} increment or decrement operation does not change the
counter value, e.g. {{UPDATE my_tab SET c = c - ? WHERE k = 1}} does change
the value of counter {{c}}
** On a tuple field or UDT field throws {{InvalidRequestException}}
* An unset bind variable in a QUERY request
** On a partition column, clustering column or index column in the {{WHERE}}
clause throws {{InvalidRequestException}}
** On the {{limit}} clause is treated as 'unlimited'
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[
https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-7304:
Reviewer: Benjamin Lerer (was: Sylvain Lebresne)
Ability to distinguish between NULL and UNSET values in Prepared Statements
---
Key: CASSANDRA-7304
URL: https://issues.apache.org/jira/browse/CASSANDRA-7304
Project: Cassandra
Issue Type: Sub-task
Reporter: Drew Kutcharian
Assignee: Oded Peer
Labels: cql, protocolv4
Fix For: 3.0
Attachments: 7304-03.patch, 7304-04.patch, 7304-2.patch, 7304.patch
Currently Cassandra inserts tombstones when a value of a column is bound to
NULL in a prepared statement. At higher insert rates managing all these
tombstones becomes an unnecessary overhead. This limits the usefulness of the
prepared statements since developers have to either create multiple prepared
statements (each with a different combination of column names, which at times
is just unfeasible because of the sheer number of possible combinations) or
fall back to using regular (non-prepared) statements.
This JIRA is here to explore the possibility of either:
A. Have a flag on prepared statements that once set, tells Cassandra to
ignore null columns
or
B. Have an UNSET value which makes Cassandra skip the null columns and not
tombstone them
Basically, in the context of a prepared statement, a null value means delete,
but we don’t have anything that means ignore (besides creating a new
prepared statement without the ignored column).
Please refer to the original conversation on DataStax Java Driver mailing
list for more background:
https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion
*EDIT 18/12/14 - [~odpeer] Implementation Notes:*
The motivation hasn't changed.
Protocol version 4 specifies that bind variables do not require having a
value when executing a statement. Bind variables without a value are called
'unset'. The 'unset' bind variable is serialized as the int value '-2'
without following bytes.
\\
\\
* An unset bind variable in an EXECUTE or BATCH request
** On a {{value}} does not modify the value and does not create a tombstone
** On the {{ttl}} clause is treated as 'unlimited'
** On the {{timestamp}} clause is treated as 'now'
** On a map key or a list index throws {{InvalidRequestException}}
** On a {{counter}} increment or decrement operation does not change the
counter value, e.g. {{UPDATE my_tab SET c = c - ? WHERE k = 1}} does change
the value of counter {{c}}
** On a tuple field or UDT field throws {{InvalidRequestException}}
* An unset bind variable in a QUERY request
** On a partition column, clustering column or index column in the {{WHERE}}
clause throws {{InvalidRequestException}}
** On the {{limit}} clause is treated as 'unlimited'
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[
https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oded Peer updated CASSANDRA-7304:
-
Description:
Currently Cassandra inserts tombstones when a value of a column is bound to
NULL in a prepared statement. At higher insert rates managing all these
tombstones becomes an unnecessary overhead. This limits the usefulness of the
prepared statements since developers have to either create multiple prepared
statements (each with a different combination of column names, which at times
is just unfeasible because of the sheer number of possible combinations) or
fall back to using regular (non-prepared) statements.
This JIRA is here to explore the possibility of either:
A. Have a flag on prepared statements that once set, tells Cassandra to ignore
null columns
or
B. Have an UNSET value which makes Cassandra skip the null columns and not
tombstone them
Basically, in the context of a prepared statement, a null value means delete,
but we don’t have anything that means ignore (besides creating a new prepared
statement without the ignored column).
Please refer to the original conversation on DataStax Java Driver mailing list
for more background:
https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion
*EDIT 18/12/14 - [~odpeer] Implementation Notes:*
The motivation hasn't changed.
Protocol version 4 specifies that bind variables do not require having a value
when executing a statement. Bind variables without a value are called 'unset'.
The 'unset' bind variable is serialized as the int value '-2' without following
bytes.
\\
\\
* An unset bind variable in an EXECUTE or BATCH request
** On a {{value}} does not modify the value and does not create a tombstone
** On the {{ttl}} clause is treated as 'unlimited'
** On the {{timestamp}} clause is treated as 'now'
** On a map key or a list index throws {{InvalidRequestException}}
** On a {{counter}} increment or decrement operation does not change the
counter value, e.g. {{UPDATE my_tab SET c = c - ? WHERE k = 1}} does change the
value of counter {{c}}
** On a tuple field or UDT field throws {{InvalidRequestException}}
* An unset bind variable in a QUERY request
** On a partition column, clustering column or index column in the {{WHERE}}
clause throws {{InvalidRequestException}}
** On the {{limit}} clause is treated as 'unlimited'
was:
Currently Cassandra inserts tombstones when a value of a column is bound to
NULL in a prepared statement. At higher insert rates managing all these
tombstones becomes an unnecessary overhead. This limits the usefulness of the
prepared statements since developers have to either create multiple prepared
statements (each with a different combination of column names, which at times
is just unfeasible because of the sheer number of possible combinations) or
fall back to using regular (non-prepared) statements.
This JIRA is here to explore the possibility of either:
A. Have a flag on prepared statements that once set, tells Cassandra to ignore
null columns
or
B. Have an UNSET value which makes Cassandra skip the null columns and not
tombstone them
Basically, in the context of a prepared statement, a null value means delete,
but we don’t have anything that means ignore (besides creating a new prepared
statement without the ignored column).
Please refer to the original conversation on DataStax Java Driver mailing list
for more background:
https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion
Ability to distinguish between NULL and UNSET values in Prepared Statements
---
Key: CASSANDRA-7304
URL: https://issues.apache.org/jira/browse/CASSANDRA-7304
Project: Cassandra
Issue Type: Sub-task
Reporter: Drew Kutcharian
Assignee: Oded Peer
Labels: cql, protocolv4
Fix For: 3.0
Attachments: 7304-03.patch, 7304-04.patch, 7304-2.patch, 7304.patch
Currently Cassandra inserts tombstones when a value of a column is bound to
NULL in a prepared statement. At higher insert rates managing all these
tombstones becomes an unnecessary overhead. This limits the usefulness of the
prepared statements since developers have to either create multiple prepared
statements (each with a different combination of column names, which at times
is just unfeasible because of the sheer number of possible combinations) or
fall back to using regular (non-prepared) statements.
This JIRA is here to explore the possibility of either:
A. Have a flag on prepared statements that once set, tells Cassandra to
ignore null columns
or
B. Have an UNSET value which makes Cassandra skip the null columns and not
tombstone them
Basically, in the context of a
[jira] [Updated] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[
https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oded Peer updated CASSANDRA-7304:
-
Attachment: 7304-04.patch
I appreciate your comments, they are very helpful and I am learning a lot from
them.
bq. In the spec, instead of changing the meaning of {{\[bytes\]}}, I would
rather add a new {{\[value\]}} definition that support 'unset', and use that
exclusively in the definition of values for bind variables in QUERY and EXECUTE
messages, so as to make it clear that it makes no sense in any other place. I
would then add a specific {{CBUtil.readBoundValue()}} to read those.
Done
bq. Making {{UNSET_CONSTANT_VALUE}} be {{new Value(null)}} is somewhat
incorrect, it should be {{new Value(UNSET_BYTE_BUFFER)}} so that we don't lose
the the information that it's 'unset' if {{bindAndGet}} is used. For this
reason, I'd prefer using {{Constants.UNSET_CONSTANT_VALUE}} (renamed as
{{UNSET_VALUE}}) in collections too (instead of adding
{{Lists.UNSET_LIST_VALUE}}, ...).
Done
bq. We can't have an 'unset' value inside a collection since we don't allow
bind markers in the first place, and so there is a bit of useless
code/validation related to that.
I verified the changes aren’t useless with unit tests.
bq. There is a bunch of place that don't handle 'UNSET_BYTE_BUFFER' properly:
Tuples, ColumnCondition (we might want to reject queries for which all
conditions are 'unset' as going through the paxos code for no reason feels like
the user is doing something wrong) and SelectStatement where we could get an
'unset' pretty much anywhere where the {{values()}} or {{bound()}} method of a
{{Restriction}} is used (and validation might be tricky in SelectStatement: if
we have {{SELECT * FROM foo WHERE k1 = ? AND k2 = ? AND k3 = ?}}, then we
shouldn't accept an 'unset' for {{k2}} unless {{k3}} is also unset; note that
I'd be fine just refusing 'unset' in selects for now to simplify, but we at
least need the validation code to reject them).
I opted for rejecting unset values in selects. It’s not only to simplify I
think it’s the right thing to do. Having a variable assignment or a condition
with unset variables is undefined.
bq. I'd reject 'unset' indexes in {{UDPATE ... SET l\[?\] = ?}} since it's
rejected for map keys. Unless maybe if both the key/index and value are
'unset', but that should be coherent for lists and maps.
Done
bq. In Constants.Marker.bindAndGet, we should skip validation if 'unset' (even
though the validation will never fail because empty values are always accepted,
it's still dodgy).
Done
bq. We should have separate error messages when we reject both {{null}} and
{{unset}}.
Done
bq. I'd prefer rejecting 'unset' inside UDTs (and tuples). Making it equivalent
to {{null}} gives it a different meaning than usual and we should avoid that.
Done
bq. For the limit in SelectStatement, it would make sense to accept unset and
to have it mean no limit (instead of being rejected). The same applies for
the timestamp and ttl in {{Attributes}}.
Done
bq. In CBUtil.readValue(), we should throw a ProtocolException instead of an
IllegalArgumentException.
Done
bq. I might have put {{UNSET_BYTE_BUFFER}} in {{ByteBufferUtil}} since it's a
{{ByteBuffer}}.
Done
bq. The patch appears to have windows end-of-line and a few weird indentations.
Could you check that?
My apologies. I switched to Ubuntu.
bq. I'd have added an unset() in CQLTester to use in tests to make the tests
terser.
Done
Ability to distinguish between NULL and UNSET values in Prepared Statements
---
Key: CASSANDRA-7304
URL: https://issues.apache.org/jira/browse/CASSANDRA-7304
Project: Cassandra
Issue Type: Sub-task
Reporter: Drew Kutcharian
Assignee: Oded Peer
Labels: cql, protocolv4
Fix For: 3.0
Attachments: 7304-03.patch, 7304-04.patch, 7304-2.patch, 7304.patch
Currently Cassandra inserts tombstones when a value of a column is bound to
NULL in a prepared statement. At higher insert rates managing all these
tombstones becomes an unnecessary overhead. This limits the usefulness of the
prepared statements since developers have to either create multiple prepared
statements (each with a different combination of column names, which at times
is just unfeasible because of the sheer number of possible combinations) or
fall back to using regular (non-prepared) statements.
This JIRA is here to explore the possibility of either:
A. Have a flag on prepared statements that once set, tells Cassandra to
ignore null columns
or
B. Have an UNSET value which makes Cassandra skip the null columns and not
tombstone them
Basically, in the context of a prepared statement, a null value means delete,
but we don’t have anything that
[jira] [Updated] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[
https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oded Peer updated CASSANDRA-7304:
-
Attachment: 4476-5.patch
[~blerer]
Added 4476-5.patch
I updated the code to scan a restricted range if there are two expressions on
the same column.
{quote}I think that you should use isRange or isSlice instead of
isRelationalOrderOperator as it is clearer.{quote}
I renamed the method.
{quote}The name of test class: SecondaryIndexNonEqTest is misleading. CONTAINS
an CONTAINS KEY operator are also non eq tests.{quote}
I renamed the test.
{quote}In getRelationalOrderEstimatedSize I do not understand why you do not
return 0 if estimatedKeysForRange return 0. Could you explain?{quote}
I added comments to the code since I think it should documented in the code and
not in Jira.
I hope it is understandable.
{quote}Instead of doing some dangerous casting in
getRelationalOrderEstimatedSize, you should change the type from bestMeanCount
from int to long.{quote}
I changed the type of bestMeanCount
{quote}In computeNext I do not understand why you do not check for stale data
for range queries? Could you explain?{quote}
I added comments to the code.
{quote}I think it would be nicer to have also an iterator for EQ and use
polymorphism instead of if else.{quote}
Generally I agree polymorphism is good practice, however I think in this case
it would make the code less readable.
{quote}The close method of the AbstractScanIterator returned by
getSequentialIterator should be called from the close method.{quote}
Thanks. I wasn't aware the iterator is closeable, they usually aren't.
{quote}The Unit tests are only covering a subset of the possible queries. Could
you add more (a 3 and a 4, a 3 and a 4 ...){quote}
Added.
{quote}When testing for InvalidRequestException you should use
assertInvalidMessage{quote}
Thanks, I wanted to use such a method but couldn't find it on my own.
[~jjordan]
I don't understand the problem in your example. The query result seems valid to
me.
In addition, can you please explain how a query using only secondary indexes
such as {{select k from my_table where index1 = 5 and index2 10 allow
filtering}} retains token order?
Ability to distinguish between NULL and UNSET values in Prepared Statements
---
Key: CASSANDRA-7304
URL: https://issues.apache.org/jira/browse/CASSANDRA-7304
Project: Cassandra
Issue Type: Sub-task
Reporter: Drew Kutcharian
Assignee: Oded Peer
Labels: cql, protocolv4
Fix For: 3.0
Attachments: 7304-03.patch, 7304-2.patch, 7304.patch
Currently Cassandra inserts tombstones when a value of a column is bound to
NULL in a prepared statement. At higher insert rates managing all these
tombstones becomes an unnecessary overhead. This limits the usefulness of the
prepared statements since developers have to either create multiple prepared
statements (each with a different combination of column names, which at times
is just unfeasible because of the sheer number of possible combinations) or
fall back to using regular (non-prepared) statements.
This JIRA is here to explore the possibility of either:
A. Have a flag on prepared statements that once set, tells Cassandra to
ignore null columns
or
B. Have an UNSET value which makes Cassandra skip the null columns and not
tombstone them
Basically, in the context of a prepared statement, a null value means delete,
but we don’t have anything that means ignore (besides creating a new
prepared statement without the ignored column).
Please refer to the original conversation on DataStax Java Driver mailing
list for more background:
https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[ https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oded Peer updated CASSANDRA-7304: - Attachment: (was: 4476-5.patch) Ability to distinguish between NULL and UNSET values in Prepared Statements --- Key: CASSANDRA-7304 URL: https://issues.apache.org/jira/browse/CASSANDRA-7304 Project: Cassandra Issue Type: Sub-task Reporter: Drew Kutcharian Assignee: Oded Peer Labels: cql, protocolv4 Fix For: 3.0 Attachments: 7304-03.patch, 7304-2.patch, 7304.patch Currently Cassandra inserts tombstones when a value of a column is bound to NULL in a prepared statement. At higher insert rates managing all these tombstones becomes an unnecessary overhead. This limits the usefulness of the prepared statements since developers have to either create multiple prepared statements (each with a different combination of column names, which at times is just unfeasible because of the sheer number of possible combinations) or fall back to using regular (non-prepared) statements. This JIRA is here to explore the possibility of either: A. Have a flag on prepared statements that once set, tells Cassandra to ignore null columns or B. Have an UNSET value which makes Cassandra skip the null columns and not tombstone them Basically, in the context of a prepared statement, a null value means delete, but we don’t have anything that means ignore (besides creating a new prepared statement without the ignored column). Please refer to the original conversation on DataStax Java Driver mailing list for more background: https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[
https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oded Peer updated CASSANDRA-7304:
-
Attachment: 7304-03.patch
7304-03.patch contents:
* Updated the v4 spec doc
* Handled backward compatilbilty in {{CBUtil.readValue}} by inspecting the
version protocol
* Reverted modifications to CQLTester
* Handled collections and counters
* Since a UDT value is always written in its entirety Cassandra can't preserve
a pre-existing value by 'not setting' the new value. unset values in UDT are
treated as null values.
* Added tests for collections and counters and UDT
Ability to distinguish between NULL and UNSET values in Prepared Statements
---
Key: CASSANDRA-7304
URL: https://issues.apache.org/jira/browse/CASSANDRA-7304
Project: Cassandra
Issue Type: Sub-task
Reporter: Drew Kutcharian
Labels: cql, protocolv4
Fix For: 3.0
Attachments: 7304-03.patch, 7304-2.patch, 7304.patch
Currently Cassandra inserts tombstones when a value of a column is bound to
NULL in a prepared statement. At higher insert rates managing all these
tombstones becomes an unnecessary overhead. This limits the usefulness of the
prepared statements since developers have to either create multiple prepared
statements (each with a different combination of column names, which at times
is just unfeasible because of the sheer number of possible combinations) or
fall back to using regular (non-prepared) statements.
This JIRA is here to explore the possibility of either:
A. Have a flag on prepared statements that once set, tells Cassandra to
ignore null columns
or
B. Have an UNSET value which makes Cassandra skip the null columns and not
tombstone them
Basically, in the context of a prepared statement, a null value means delete,
but we don’t have anything that means ignore (besides creating a new
prepared statement without the ignored column).
Please refer to the original conversation on DataStax Java Driver mailing
list for more background:
https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[ https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-7304: Issue Type: Sub-task (was: Improvement) Parent: CASSANDRA-8043 Ability to distinguish between NULL and UNSET values in Prepared Statements --- Key: CASSANDRA-7304 URL: https://issues.apache.org/jira/browse/CASSANDRA-7304 Project: Cassandra Issue Type: Sub-task Reporter: Drew Kutcharian Labels: cql, protocolv4 Fix For: 3.0 Attachments: 7304-2.patch, 7304.patch Currently Cassandra inserts tombstones when a value of a column is bound to NULL in a prepared statement. At higher insert rates managing all these tombstones becomes an unnecessary overhead. This limits the usefulness of the prepared statements since developers have to either create multiple prepared statements (each with a different combination of column names, which at times is just unfeasible because of the sheer number of possible combinations) or fall back to using regular (non-prepared) statements. This JIRA is here to explore the possibility of either: A. Have a flag on prepared statements that once set, tells Cassandra to ignore null columns or B. Have an UNSET value which makes Cassandra skip the null columns and not tombstone them Basically, in the context of a prepared statement, a null value means delete, but we don’t have anything that means ignore (besides creating a new prepared statement without the ignored column). Please refer to the original conversation on DataStax Java Driver mailing list for more background: https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[ https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oded Peer updated CASSANDRA-7304: - Attachment: 7304-2.patch Ability to distinguish between NULL and UNSET values in Prepared Statements --- Key: CASSANDRA-7304 URL: https://issues.apache.org/jira/browse/CASSANDRA-7304 Project: Cassandra Issue Type: Improvement Reporter: Drew Kutcharian Labels: cql, protocolv4 Attachments: 7304-2.patch, 7304.patch Currently Cassandra inserts tombstones when a value of a column is bound to NULL in a prepared statement. At higher insert rates managing all these tombstones becomes an unnecessary overhead. This limits the usefulness of the prepared statements since developers have to either create multiple prepared statements (each with a different combination of column names, which at times is just unfeasible because of the sheer number of possible combinations) or fall back to using regular (non-prepared) statements. This JIRA is here to explore the possibility of either: A. Have a flag on prepared statements that once set, tells Cassandra to ignore null columns or B. Have an UNSET value which makes Cassandra skip the null columns and not tombstone them Basically, in the context of a prepared statement, a null value means delete, but we don’t have anything that means ignore (besides creating a new prepared statement without the ignored column). Please refer to the original conversation on DataStax Java Driver mailing list for more background: https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[ https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-7304: Fix Version/s: 3.0 Ability to distinguish between NULL and UNSET values in Prepared Statements --- Key: CASSANDRA-7304 URL: https://issues.apache.org/jira/browse/CASSANDRA-7304 Project: Cassandra Issue Type: Improvement Reporter: Drew Kutcharian Labels: cql, protocolv4 Fix For: 3.0 Attachments: 7304-2.patch, 7304.patch Currently Cassandra inserts tombstones when a value of a column is bound to NULL in a prepared statement. At higher insert rates managing all these tombstones becomes an unnecessary overhead. This limits the usefulness of the prepared statements since developers have to either create multiple prepared statements (each with a different combination of column names, which at times is just unfeasible because of the sheer number of possible combinations) or fall back to using regular (non-prepared) statements. This JIRA is here to explore the possibility of either: A. Have a flag on prepared statements that once set, tells Cassandra to ignore null columns or B. Have an UNSET value which makes Cassandra skip the null columns and not tombstone them Basically, in the context of a prepared statement, a null value means delete, but we don’t have anything that means ignore (besides creating a new prepared statement without the ignored column). Please refer to the original conversation on DataStax Java Driver mailing list for more background: https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[ https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-7304: Reviewer: Sylvain Lebresne Ability to distinguish between NULL and UNSET values in Prepared Statements --- Key: CASSANDRA-7304 URL: https://issues.apache.org/jira/browse/CASSANDRA-7304 Project: Cassandra Issue Type: Improvement Reporter: Drew Kutcharian Labels: cql, protocolv4 Fix For: 3.0 Attachments: 7304-2.patch, 7304.patch Currently Cassandra inserts tombstones when a value of a column is bound to NULL in a prepared statement. At higher insert rates managing all these tombstones becomes an unnecessary overhead. This limits the usefulness of the prepared statements since developers have to either create multiple prepared statements (each with a different combination of column names, which at times is just unfeasible because of the sheer number of possible combinations) or fall back to using regular (non-prepared) statements. This JIRA is here to explore the possibility of either: A. Have a flag on prepared statements that once set, tells Cassandra to ignore null columns or B. Have an UNSET value which makes Cassandra skip the null columns and not tombstone them Basically, in the context of a prepared statement, a null value means delete, but we don’t have anything that means ignore (besides creating a new prepared statement without the ignored column). Please refer to the original conversation on DataStax Java Driver mailing list for more background: https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[ https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-7304: Labels: cql protocolv4 (was: cql) Ability to distinguish between NULL and UNSET values in Prepared Statements --- Key: CASSANDRA-7304 URL: https://issues.apache.org/jira/browse/CASSANDRA-7304 Project: Cassandra Issue Type: Improvement Reporter: Drew Kutcharian Labels: cql, protocolv4 Attachments: 7304.patch Currently Cassandra inserts tombstones when a value of a column is bound to NULL in a prepared statement. At higher insert rates managing all these tombstones becomes an unnecessary overhead. This limits the usefulness of the prepared statements since developers have to either create multiple prepared statements (each with a different combination of column names, which at times is just unfeasible because of the sheer number of possible combinations) or fall back to using regular (non-prepared) statements. This JIRA is here to explore the possibility of either: A. Have a flag on prepared statements that once set, tells Cassandra to ignore null columns or B. Have an UNSET value which makes Cassandra skip the null columns and not tombstone them Basically, in the context of a prepared statement, a null value means delete, but we don’t have anything that means ignore (besides creating a new prepared statement without the ignored column). Please refer to the original conversation on DataStax Java Driver mailing list for more background: https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[ https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-7304: Labels: cql (was: ) Ability to distinguish between NULL and UNSET values in Prepared Statements --- Key: CASSANDRA-7304 URL: https://issues.apache.org/jira/browse/CASSANDRA-7304 Project: Cassandra Issue Type: Improvement Reporter: Drew Kutcharian Labels: cql Attachments: 7304.patch Currently Cassandra inserts tombstones when a value of a column is bound to NULL in a prepared statement. At higher insert rates managing all these tombstones becomes an unnecessary overhead. This limits the usefulness of the prepared statements since developers have to either create multiple prepared statements (each with a different combination of column names, which at times is just unfeasible because of the sheer number of possible combinations) or fall back to using regular (non-prepared) statements. This JIRA is here to explore the possibility of either: A. Have a flag on prepared statements that once set, tells Cassandra to ignore null columns or B. Have an UNSET value which makes Cassandra skip the null columns and not tombstone them Basically, in the context of a prepared statement, a null value means delete, but we don’t have anything that means ignore (besides creating a new prepared statement without the ignored column). Please refer to the original conversation on DataStax Java Driver mailing list for more background: https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[ https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oded Peer updated CASSANDRA-7304: - Attachment: 7304.patch Ability to distinguish between NULL and UNSET values in Prepared Statements --- Key: CASSANDRA-7304 URL: https://issues.apache.org/jira/browse/CASSANDRA-7304 Project: Cassandra Issue Type: Improvement Reporter: Drew Kutcharian Attachments: 7304.patch Currently Cassandra inserts tombstones when a value of a column is bound to NULL in a prepared statement. At higher insert rates managing all these tombstones becomes an unnecessary overhead. This limits the usefulness of the prepared statements since developers have to either create multiple prepared statements (each with a different combination of column names, which at times is just unfeasible because of the sheer number of possible combinations) or fall back to using regular (non-prepared) statements. This JIRA is here to explore the possibility of either: A. Have a flag on prepared statements that once set, tells Cassandra to ignore null columns or B. Have an UNSET value which makes Cassandra skip the null columns and not tombstone them Basically, in the context of a prepared statement, a null value means delete, but we don’t have anything that means ignore (besides creating a new prepared statement without the ignored column). Please refer to the original conversation on DataStax Java Driver mailing list for more background: https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion -- This message was sent by Atlassian JIRA (v6.2#6252)
