You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@phoenix.apache.org by Mohamed Ibrahim <m0...@gmail.com> on 2014/09/21 02:16:53 UTC
Issue with maintaining the index with not null in table definition
Hi All,
I faced an issue where wrong values started appearing in my queries, values
that I did not insert into the table. Those values appeared after upserting
(updating) an existing row.
By debugging, I found that if I create a table with a bigint not null
column, then create an index on that column updating an existing row
results in what it seems corrupted values.
I'm using phoenix 3.0, and saved the sqline output in a gist here (
https://gist.github.com/mibrahim/6ebbd254412a3648ad7e ).
Steps to reproduce:
1. Create a table with a bigint not null field
2. Create an index on that field
3. upsert a row
4. update (upsert) a row with an existing primary key
errors show in the table.
I removed the not null from my application so it's not blocking me, but I
believe it is a bug.
Thanks,
Mohamed
Re: Issue with maintaining the index with not null in table definition
Posted by Mohamed Ibrahim <m0...@gmail.com>.
Super.
Thanks for the update & fix,
Mohamed
On Sun, Sep 21, 2014 at 2:11 AM, James Taylor <ja...@apache.org>
wrote:
> Hi Mohamed,
> Thanks for the detail on this issue. I filed and fixed the issue with
> declaring a NOT NULL constraint on a non PK column (PHOENIX-1266).
> We've never enforced a NOT NULL constraint on a non PK column, so we
> shouldn't allow a declaration of it. Note that in most cases we
> already caught this and disallowed it, but this was a slightly
> different case that wasn't being flagged as an error.
>
> I also filed HBASE-12039 for the warning you're seeing in sqlline. You
> can safely ignore it.
>
> I verified that without the declaration of the NOT NULL constraint,
> everything works fine with the index in place (and I made sure that
> existing tables that may have been declared this way will not cause
> this same indexing issue you're seeing).
>
> Regards,
> James
>
>
> On Sat, Sep 20, 2014 at 5:16 PM, Mohamed Ibrahim <m0...@gmail.com> wrote:
> > Hi All,
> >
> > I faced an issue where wrong values started appearing in my queries,
> values
> > that I did not insert into the table. Those values appeared after
> upserting
> > (updating) an existing row.
> >
> > By debugging, I found that if I create a table with a bigint not null
> > column, then create an index on that column updating an existing row
> results
> > in what it seems corrupted values.
> >
> > I'm using phoenix 3.0, and saved the sqline output in a gist here (
> > https://gist.github.com/mibrahim/6ebbd254412a3648ad7e ).
> >
> > Steps to reproduce:
> > 1. Create a table with a bigint not null field
> > 2. Create an index on that field
> > 3. upsert a row
> > 4. update (upsert) a row with an existing primary key
> >
> > errors show in the table.
> >
> > I removed the not null from my application so it's not blocking me, but I
> > believe it is a bug.
> >
> > Thanks,
> > Mohamed
>
Re: Issue with maintaining the index with not null in table definition
Posted by James Taylor <ja...@apache.org>.
Hi Mohamed,
Thanks for the detail on this issue. I filed and fixed the issue with
declaring a NOT NULL constraint on a non PK column (PHOENIX-1266).
We've never enforced a NOT NULL constraint on a non PK column, so we
shouldn't allow a declaration of it. Note that in most cases we
already caught this and disallowed it, but this was a slightly
different case that wasn't being flagged as an error.
I also filed HBASE-12039 for the warning you're seeing in sqlline. You
can safely ignore it.
I verified that without the declaration of the NOT NULL constraint,
everything works fine with the index in place (and I made sure that
existing tables that may have been declared this way will not cause
this same indexing issue you're seeing).
Regards,
James
On Sat, Sep 20, 2014 at 5:16 PM, Mohamed Ibrahim <m0...@gmail.com> wrote:
> Hi All,
>
> I faced an issue where wrong values started appearing in my queries, values
> that I did not insert into the table. Those values appeared after upserting
> (updating) an existing row.
>
> By debugging, I found that if I create a table with a bigint not null
> column, then create an index on that column updating an existing row results
> in what it seems corrupted values.
>
> I'm using phoenix 3.0, and saved the sqline output in a gist here (
> https://gist.github.com/mibrahim/6ebbd254412a3648ad7e ).
>
> Steps to reproduce:
> 1. Create a table with a bigint not null field
> 2. Create an index on that field
> 3. upsert a row
> 4. update (upsert) a row with an existing primary key
>
> errors show in the table.
>
> I removed the not null from my application so it's not blocking me, but I
> believe it is a bug.
>
> Thanks,
> Mohamed