Super. Thanks for the update & fix, Mohamed On Sun, Sep 21, 2014 at 2:11 AM, James Taylor <[email protected]> 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 <[email protected]> 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 >
