You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@phoenix.apache.org by Steve Terrell <st...@oculus360.us> on 2016/02/23 21:52:37 UTC
Looks Like a SELECT Bug, But LIMIT Makes It Work
I came across a 4.6.0 query that I could not make work unless I add a
"limit" to the end, where it should be totally unnecessary.
select * from BUGGY where F1=1 and F3 is null
results in no records found
select * from BUGGY where F1=1 and F3 is null limit 999
results (correctly) in one record found
I think it's a bug where Phoenix gets confused about my HBase columns and
views. Here's how to set up the table to duplicate my problem:
CREATE TABLE BUGGY (
F1 INTEGER NOT NULL,
A.F2 INTEGER,
B.F3 INTEGER,
CONSTRAINT my_pk PRIMARY KEY (F1));
create view if not exists BUGGY_A as select * from BUGGY;
alter view BUGGY_A drop column if exists F3;
create view if not exists BUGGY_B as select * from BUGGY;
alter view BUGGY_B drop column if exists F2;
upsert into BUGGY(F1) values (1)
Do you think I should file a JIRA for this? Or is it a misunderstanding on
my part?
Thank you,
Steve
Re: Looks Like a SELECT Bug, But LIMIT Makes It Work
Posted by Steve Terrell <st...@oculus360.us>.
Done! https://issues.apache.org/jira/browse/PHOENIX-2709 .
On Tue, Feb 23, 2016 at 3:15 PM, Sergey Soldatov <se...@gmail.com>
wrote:
> Hi Steve,
> It looks like a bug. So, please file a JIRA.
>
> Thanks,
> Sergey
>
> On Tue, Feb 23, 2016 at 12:52 PM, Steve Terrell <st...@oculus360.us>
> wrote:
> > I came across a 4.6.0 query that I could not make work unless I add a
> > "limit" to the end, where it should be totally unnecessary.
> >
> > select * from BUGGY where F1=1 and F3 is null
> > results in no records found
> >
> > select * from BUGGY where F1=1 and F3 is null limit 999
> > results (correctly) in one record found
> >
> > I think it's a bug where Phoenix gets confused about my HBase columns and
> > views. Here's how to set up the table to duplicate my problem:
> >
> > CREATE TABLE BUGGY (
> > F1 INTEGER NOT NULL,
> > A.F2 INTEGER,
> > B.F3 INTEGER,
> > CONSTRAINT my_pk PRIMARY KEY (F1));
> > create view if not exists BUGGY_A as select * from BUGGY;
> > alter view BUGGY_A drop column if exists F3;
> > create view if not exists BUGGY_B as select * from BUGGY;
> > alter view BUGGY_B drop column if exists F2;
> > upsert into BUGGY(F1) values (1)
> >
> > Do you think I should file a JIRA for this? Or is it a misunderstanding
> on
> > my part?
> >
> > Thank you,
> > Steve
>
Re: Looks Like a SELECT Bug, But LIMIT Makes It Work
Posted by Sergey Soldatov <se...@gmail.com>.
Hi Steve,
It looks like a bug. So, please file a JIRA.
Thanks,
Sergey
On Tue, Feb 23, 2016 at 12:52 PM, Steve Terrell <st...@oculus360.us> wrote:
> I came across a 4.6.0 query that I could not make work unless I add a
> "limit" to the end, where it should be totally unnecessary.
>
> select * from BUGGY where F1=1 and F3 is null
> results in no records found
>
> select * from BUGGY where F1=1 and F3 is null limit 999
> results (correctly) in one record found
>
> I think it's a bug where Phoenix gets confused about my HBase columns and
> views. Here's how to set up the table to duplicate my problem:
>
> CREATE TABLE BUGGY (
> F1 INTEGER NOT NULL,
> A.F2 INTEGER,
> B.F3 INTEGER,
> CONSTRAINT my_pk PRIMARY KEY (F1));
> create view if not exists BUGGY_A as select * from BUGGY;
> alter view BUGGY_A drop column if exists F3;
> create view if not exists BUGGY_B as select * from BUGGY;
> alter view BUGGY_B drop column if exists F2;
> upsert into BUGGY(F1) values (1)
>
> Do you think I should file a JIRA for this? Or is it a misunderstanding on
> my part?
>
> Thank you,
> Steve