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