phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Poon (JIRA)" <>
Subject [jira] [Updated] (PHOENIX-4382) Upsert of some big values not correct for immutable tables
Date Tue, 05 Dec 2017 23:31:00 GMT


Vincent Poon updated PHOENIX-4382:
    Attachment: PHOENIX-4382.v1.master.patch

This turned out to be a column encoding bug.  The data is written fine but when reading, in
PArrayDataTypeDecoder there is an optimization that checks for SEPARATOR_BYTE in the first
byte - if it's there, it is assumed the value length is 0.  This makes sense in SORTABLE_SERIALIZATION,
but for IMMUTABLE_SERIALIZATION, there are no separators.  If the data just happens to have
a first byte of 0 or -1 (SEPARATOR_BYTE or DESC_SEPARATOR_BYTE), then the optimization does
the wrong thing.  For short values > 32511, the first byte is -1, which is why this bug
was appearing.

The fix is to not do the optimization for IMMUTABLE_SERIALIZATION.

[~tdsilva] can you review ?

FYI, [~jamestaylor] [~aertoria]

> Upsert of some big values not correct for immutable tables
> ----------------------------------------------------------
>                 Key: PHOENIX-4382
>                 URL:
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.14.0
>            Reporter: Vincent Poon
>            Assignee: Vincent Poon
>         Attachments: PHOENIX-4382.v1.master.patch,
> For immutable tables, upsert of some values like Short.MAX_VALUE results in a null value
in query resultsets.  Mutable tables are not affected.  I tried with BigInt and got the same
> For Short, the breaking point seems to be 32512.  Numbers smaller than that are fine
(until you get closer to Short.MIN_VALUE...)
> See attached test - testShort() , testBigInt()

This message was sent by Atlassian JIRA

View raw message