You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sandeep Tamhankar (JIRA)" <ji...@apache.org> on 2017/04/26 00:08:04 UTC

[jira] [Commented] (CASSANDRA-13218) Duration validation error is unclear in case of overflow.

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

Sandeep Tamhankar commented on CASSANDRA-13218:
-----------------------------------------------

Found a few other bad side effects of the current behavior:

1. The validated (truncated) values are not actually re-encoded to vint's and stored; the user-provided bytes are stored. This is bad because it introduces an inconsistency of behavior -- a client can insert/select 64-bit values for months and days, but when C* exports the data as json (for example), the Duration.deserialize method will produce an object with truncated values.
2. Validation doesn't check for truncation error and reject the insert.
3. I think validation will succeed for this illegal set of values provided by a driver: (-9223372036854775807, 1, 1) because the months attribute will be coerced to 1 (since the highest 4 bytes will be dropped).

*Proposal 1*: accept and handle 64-bit values for months and days consistently. I don't know how often these values are used in C*, but an extra 8 bytes doesn't sound like it's worth the hassle of treating months and days differently than nanos. It makes C* code a little more complex; it makes driver code a little more complex (for drivers that are type-aware at least).
*Proposal 2*: beef up the validation logic to reject values that would overflow/underflow during long->int truncation. Write a tool that users can use to identify illegal rows they inserted because of the holes in the validation logic and give users an opportunity to clean up such bad data.

Admittedly, the chances that users have inserted illegal duration's is relatively small, particularly since this new type hasn't been around very long. But it seems much simpler to make those values legal, so I'd lean towards my first proposal.

> Duration validation error is unclear in case of overflow.
> ---------------------------------------------------------
>
>                 Key: CASSANDRA-13218
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13218
>             Project: Cassandra
>          Issue Type: Bug
>          Components: CQL
>            Reporter: Benjamin Lerer
>            Assignee: Benjamin Lerer
>             Fix For: 3.11.x
>
>
> If a user try to insert a {{duration}} with a number of months or days that cannot fit in an {{int}} (for example: {{9223372036854775807mo1d}}), the error message is confusing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)