HI James, Thanks for the feedback. That's great. We were blasting everything out and starting from scratch each time we went back and forth. I will test it out. We will be doing both M/R and interacting with JDBC. Thanks! Abe On Fri, Apr 4, 2014 at 11:16 AM, James Taylor wrote: > Existing date/time types are now represented by UNSIGNED_DATE, > UNSIGNED_TIME, and UNSIGNED_TIMESTAMP. If you have code that matches on > DATE, TIME, or TIMESTAMP, it should be changed to use the UNSIGNED > equivalent. > > Also, not sure if you've done this yet, but you should run your tables > through our upgrade process: > http://phoenix.incubator.apache.org/upgrade_from_2_2.html > > This will (among other things), change the metadata as described above (so > if you're not explicitly referencing PDataType date/time types, but driving > off of the DatabaseMetaData calls, no change would be necessary). > > The reason we made this change, is so that we can support negative > date/time values (which we've had a few requests for). > > Thanks, > James > > > > > On Fri, Apr 4, 2014 at 8:03 AM, Abe Weinograd wrote: > >> We are bulk loading rows into our HBase tables directly via M/R -> >> HFiles. This worked well in 2.2.3 and has broken with 3.0. >> >> We have a 3 column PK (int, date, int). When I insert directly via the >> JDBC driver, everything works well. When loading via the HFile, logging >> the Hex String from our M/R job and doing a scan on the table in the hbase >> shell, it shows this: >> >> The first 12 bytes (int then date) of our key looks like this on the >> scan: >> \x00\x00\x00\x06\x00\x00\x1D\x8F\xD5&\x84\x00 >> >> x00\x00\x1D\x8F\xD5&\x84\x00 was supposed to represent 12/31/2999 >> 00:00:00 UTC >> The long value is 32503593600000L >> >> We are using hbase client util Bytes.toBytes(32503593600000L) to get our >> value. It seems like a change in the PDataType code causes this not to >> work anymore with 3.0. >> >> Does this make sense? Is there an easy way for us to fix it? I know the >> Bytes.toBytes() representation looks funny with the & in it, but it seems >> to work across the board. >> >> Any ideas how we can work around this? >> >> Thanks, >> Abe >> > >