phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Heppner <heppner.m...@gmail.com>
Subject Re: Inconsistent null behavior
Date Thu, 08 Dec 2016 15:28:27 GMT
Increasing it from the default of 2 MB to 8 MB seemed to fix it for me,
thanks.

On Wed, Dec 7, 2016 at 12:38 AM, Ankit Singhal <ankitsinghal59@gmail.com>
wrote:

>
> @James, is this similar to https://issues.apache.org/
> jira/browse/PHOENIX-3112?
> @Mac, can you try if increasing hbase.client.scanner.max.result.size
> helps?
>
> On Tue, Dec 6, 2016 at 10:53 PM, James Taylor <jamestaylor@apache.org>
> wrote:
>
>> Looks like a bug to me. If you can reproduce the issue outside of Python
>> phoenixdb, using the Query Server directly, please file a JIRA. If not, it
>> sounds like a Phython phoenixdb issue.
>>
>> Thanks,
>> James
>>
>> On Tue, Dec 6, 2016 at 8:58 AM, Mark Heppner <heppner.mark@gmail.com>
>> wrote:
>>
>>> I encountered something interesting and I'm not sure if it's a bug in
>>> Phoenix itself, the query server, or just a side effect of using a large
>>> binary column. If I create a table like this (in sqlline):
>>>     create table test1 (
>>>         id integer not null primary key,
>>>         image varbinary,
>>>         height unsigned_int,
>>>         width unsigned_int
>>>     )
>>>
>>> And insert with the Python phoenixdb client (uses the query server):
>>>     with phoenixdb.connect('http://localhost:8765', autocommit=True) as
>>> con:
>>>         with con.cursor() as cur:
>>>             cur.execute('upsert into test1 values(?, ?, ?, ?)', [1, img,
>>> 900, 900])
>>>
>>> When I "select * from test1" using sqlline, the width column appears as
>>> null:
>>>     +-----+--------------+---------+--------+
>>>     | ID  |    IMAGE     | HEIGHT  | WIDTH  |
>>>     +-----+--------------+---------+--------+
>>>     | 1   | [B@5a2bd7c8  | 900     | null   |
>>>     +-----+--------------+---------+--------+
>>>
>>> However, using "select width from test1", it returns the value:
>>>     +--------+
>>>     | WIDTH  |
>>>     +--------+
>>>     | 900    |
>>>     +--------+
>>>
>>> Filtering by null using "select * from test1 where width is null" gives
>>> 0 rows, so it's like the value is there but doesn't get recognized when
>>> using a "select *".
>>>
>>> The value does show up when the binary column is not included in the
>>> select (select id, height, width). If the binary column is present, it
>>> appears as null (select image, height, width).
>>>
>>> This behavior can be confirmed with phoenixdb too:
>>>     > cur.execute('select width from test1')
>>>     > cur.fetchall()
>>>     [[900]]
>>>
>>>     > cur.execute('select * from test1')
>>>     > cur.fetchall()
>>>     [[1, '\x00\x01 ...', 900, None]]
>>>
>>> I don't think this is an issue with phoenixdb, since I can see the
>>> protobuf message serializing both the height and width columns the same
>>> way. Is this an issue with Phoenix itself, or just something the query
>>> server did on upsert?
>>>
>>> Is this a side effect of using a large binary column (typical length is
>>> 6480000)? In sqlline, using this works:
>>>
>>>     upsert into test1 values (2, '\x00\x01\x02', 900, 900);
>>>     select * from test1;
>>>
>>>     +-----+--------------+---------+--------+
>>>     | ID  |    IMAGE     | HEIGHT  | WIDTH  |
>>>     +-----+--------------+---------+--------+
>>>     | 1   | [B@1835d3ed  | 900     | null   |
>>>     | 2   | [B@66213a0d  | 900     | 900    |
>>>     +-----+--------------+---------+--------+
>>>
>>> Also worth mentioning, this never happens to the height column; it
>>> always has the correct value. It's only happening on width, the second of
>>> the unsigned_int columns.
>>>
>>> HBase 1.1.2 and Phoenix 4.7 from HDP 2.5.
>>>
>>
>>
>


-- 
Mark Heppner

Mime
View raw message