[jira] [Updated] (PHOENIX-4382) Immutable table SINGLE_CELL_ARRAY_WITH_OFFSETS values starting with separator byte return null in query results
[ https://issues.apache.org/jira/browse/PHOENIX-4382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated PHOENIX-4382: Fix Version/s: (was: 5.0) 5.0.0-alpha > Immutable table SINGLE_CELL_ARRAY_WITH_OFFSETS values starting with separator > byte return null in query results > --- > > Key: PHOENIX-4382 > URL: https://issues.apache.org/jira/browse/PHOENIX-4382 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.14.0 >Reporter: Vincent Poon >Assignee: Vincent Poon >Priority: Major > Fix For: 5.0.0-alpha, 4.14.0, 4.13.2, 4.13.2-cdh5.11.2 > > Attachments: PHOENIX-4382.v1.master.patch, > PHOENIX-4382.v2.master.patch, PHOENIX-4382.v3.master.patch, > PHOENIX-4382.v4.master.patch, UpsertBigValuesIT.java > > > 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 problem. > For Short, the breaking point seems to be 32512. > This is happening because of the way we serialize nulls. For nulls, we write > out [separatorByte, #_of_nulls]. However, some data values, like > Short.MAX_VALUE, start with separatorByte, we can't distinguish between a > null and these values. Currently the code assumes it's a null when it sees a > leading separatorByte, hence the incorrect query results. > See attached test - testShort() , testBigInt() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4382) Immutable table SINGLE_CELL_ARRAY_WITH_OFFSETS values starting with separator byte return null in query results
[ https://issues.apache.org/jira/browse/PHOENIX-4382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-4382: -- Fix Version/s: 4.13.2-cdh5.11.2 > Immutable table SINGLE_CELL_ARRAY_WITH_OFFSETS values starting with separator > byte return null in query results > --- > > Key: PHOENIX-4382 > URL: https://issues.apache.org/jira/browse/PHOENIX-4382 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.14.0 >Reporter: Vincent Poon >Assignee: Vincent Poon >Priority: Major > Fix For: 5.0, 4.14.0, 4.13.2, 4.13.2-cdh5.11.2 > > Attachments: PHOENIX-4382.v1.master.patch, > PHOENIX-4382.v2.master.patch, PHOENIX-4382.v3.master.patch, > PHOENIX-4382.v4.master.patch, UpsertBigValuesIT.java > > > 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 problem. > For Short, the breaking point seems to be 32512. > This is happening because of the way we serialize nulls. For nulls, we write > out [separatorByte, #_of_nulls]. However, some data values, like > Short.MAX_VALUE, start with separatorByte, we can't distinguish between a > null and these values. Currently the code assumes it's a null when it sees a > leading separatorByte, hence the incorrect query results. > See attached test - testShort() , testBigInt() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4382) Immutable table SINGLE_CELL_ARRAY_WITH_OFFSETS values starting with separator byte return null in query results
[ https://issues.apache.org/jira/browse/PHOENIX-4382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-4382: -- Fix Version/s: 4.13.2 > Immutable table SINGLE_CELL_ARRAY_WITH_OFFSETS values starting with separator > byte return null in query results > --- > > Key: PHOENIX-4382 > URL: https://issues.apache.org/jira/browse/PHOENIX-4382 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.14.0 >Reporter: Vincent Poon >Assignee: Vincent Poon >Priority: Major > Fix For: 5.0, 4.14.0, 4.13.2, 4.13.2-cdh5.11.2 > > Attachments: PHOENIX-4382.v1.master.patch, > PHOENIX-4382.v2.master.patch, PHOENIX-4382.v3.master.patch, > PHOENIX-4382.v4.master.patch, UpsertBigValuesIT.java > > > 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 problem. > For Short, the breaking point seems to be 32512. > This is happening because of the way we serialize nulls. For nulls, we write > out [separatorByte, #_of_nulls]. However, some data values, like > Short.MAX_VALUE, start with separatorByte, we can't distinguish between a > null and these values. Currently the code assumes it's a null when it sees a > leading separatorByte, hence the incorrect query results. > See attached test - testShort() , testBigInt() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4382) Immutable table SINGLE_CELL_ARRAY_WITH_OFFSETS values starting with separator byte return null in query results
[ https://issues.apache.org/jira/browse/PHOENIX-4382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Poon updated PHOENIX-4382: -- Attachment: PHOENIX-4382.v4.master.patch added some more comments > Immutable table SINGLE_CELL_ARRAY_WITH_OFFSETS values starting with separator > byte return null in query results > --- > > Key: PHOENIX-4382 > URL: https://issues.apache.org/jira/browse/PHOENIX-4382 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.14.0 >Reporter: Vincent Poon >Assignee: Vincent Poon > Attachments: PHOENIX-4382.v1.master.patch, > PHOENIX-4382.v2.master.patch, PHOENIX-4382.v3.master.patch, > PHOENIX-4382.v4.master.patch, UpsertBigValuesIT.java > > > 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 problem. > For Short, the breaking point seems to be 32512. > This is happening because of the way we serialize nulls. For nulls, we write > out [separatorByte, #_of_nulls]. However, some data values, like > Short.MAX_VALUE, start with separatorByte, we can't distinguish between a > null and these values. Currently the code assumes it's a null when it sees a > leading separatorByte, hence the incorrect query results. > See attached test - testShort() , testBigInt() -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4382) Immutable table SINGLE_CELL_ARRAY_WITH_OFFSETS values starting with separator byte return null in query results
[
https://issues.apache.org/jira/browse/PHOENIX-4382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Poon updated PHOENIX-4382:
--
Attachment: PHOENIX-4382.v3.master.patch
v3 patch that adds a test for single byte values, some integers that start with
separatorByte, and tests if we can differentiate {separatorByte, 2} from two
nulls.
I also renamed a method for clarity.
> Immutable table SINGLE_CELL_ARRAY_WITH_OFFSETS values starting with separator
> byte return null in query results
> ---
>
> Key: PHOENIX-4382
> URL: https://issues.apache.org/jira/browse/PHOENIX-4382
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.14.0
>Reporter: Vincent Poon
>Assignee: Vincent Poon
> Attachments: PHOENIX-4382.v1.master.patch,
> PHOENIX-4382.v2.master.patch, PHOENIX-4382.v3.master.patch,
> UpsertBigValuesIT.java
>
>
> 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 problem.
> For Short, the breaking point seems to be 32512.
> This is happening because of the way we serialize nulls. For nulls, we write
> out [separatorByte, #_of_nulls]. However, some data values, like
> Short.MAX_VALUE, start with separatorByte, we can't distinguish between a
> null and these values. Currently the code assumes it's a null when it sees a
> leading separatorByte, hence the incorrect query results.
> See attached test - testShort() , testBigInt()
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (PHOENIX-4382) Immutable table SINGLE_CELL_ARRAY_WITH_OFFSETS values starting with separator byte return null in query results
[ https://issues.apache.org/jira/browse/PHOENIX-4382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Poon updated PHOENIX-4382: -- Summary: Immutable table SINGLE_CELL_ARRAY_WITH_OFFSETS values starting with separator byte return null in query results (was: Immutable table variable length column values starting with separator byte return null in query results) > Immutable table SINGLE_CELL_ARRAY_WITH_OFFSETS values starting with separator > byte return null in query results > --- > > Key: PHOENIX-4382 > URL: https://issues.apache.org/jira/browse/PHOENIX-4382 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.14.0 >Reporter: Vincent Poon >Assignee: Vincent Poon > Attachments: PHOENIX-4382.v1.master.patch, > PHOENIX-4382.v2.master.patch, UpsertBigValuesIT.java > > > 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 problem. > For Short, the breaking point seems to be 32512. > This is happening because of the way we serialize nulls. For nulls, we write > out [separatorByte, #_of_nulls]. However, some data values, like > Short.MAX_VALUE, start with separatorByte, we can't distinguish between a > null and these values. Currently the code assumes it's a null when it sees a > leading separatorByte, hence the incorrect query results. > See attached test - testShort() , testBigInt() -- This message was sent by Atlassian JIRA (v6.4.14#64029)
