phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Taylor <jamestay...@apache.org>
Subject Re: Inconsistent null behavior
Date Tue, 06 Dec 2016 17:23:38 GMT
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.
>

Mime
View raw message