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

Reply via email to