[
https://issues.apache.org/jira/browse/PHOENIX-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15148277#comment-15148277
]
James Taylor commented on PHOENIX-2631:
---------------------------------------
I think Timestamp.setNanos() is very counterintuitive. Given that the date part
already stores millisecond granularity, it seems very odd to me that setNanos()
truncates the existing millisecond part. I would have expected it to keep only
the fractional nanos part in nanos. But it doesn't really matter, as it is the
way it is.
In Phoenix, a Timestamp is 12 bytes - the first 8 bytes are the millisecond
part and the last 4 bytes are the fractional nanos part. This allows the bytes
from a Timestamp to be compared directly against other Timestamps (because
they're normalized in the same way). The nanos will be less than 1000000 unless
it was written back in Phoenix 1.x. That code is just taking care of that b/w
compatibility issue. We restore the nanos back without removing the fractional
millisecond part from the date part.
> Exception when parsing boundary timestamp values
> ------------------------------------------------
>
> Key: PHOENIX-2631
> URL: https://issues.apache.org/jira/browse/PHOENIX-2631
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.6.0, 4.7.0
> Reporter: Nick Dimiduk
> Fix For: 4.7.0
>
> Attachments: 2631-workaround.patch
>
>
> I get a stack trace when querying or explaining a query that contains a
> timestamp value on the boundary of the day.
> {noformat}
> > CREATE TABLE FOO(
> a VARCHAR NOT NULL,
> b TIMESTAMP NOT NULL,
> c VARCHAR,
> CONSTRAINT pk PRIMARY KEY (a, b DESC ROW_TIMESTAMP, c)
> ) IMMUTABLE_ROWS=true,
> SALT_BUCKETS=20
> ;
> No rows affected (1.532 seconds)
> > explain select * from foo where a = 'a' and b >= timestamp '2016-01-28
> > 00:00:00' and b < timestamp '2016-01-29 00:00:00';
> Error: ERROR 201 (22000): Illegal data. (state=22000,code=201)
> java.sql.SQLException: ERROR 201 (22000): Illegal data.
> at
> org.apache.phoenix.exception.SQLExceptionCode$Factory$1.newException(SQLExceptionCode.java:419)
> at
> org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:145)
> at
> org.apache.phoenix.schema.types.PDataType.newIllegalDataException(PDataType.java:286)
> at
> org.apache.phoenix.schema.types.PUnsignedInt$UnsignedIntCodec.decodeInt(PUnsignedInt.java:165)
> at
> org.apache.phoenix.schema.types.PTimestamp.toObject(PTimestamp.java:108)
> at
> org.apache.phoenix.schema.types.PTimestamp.toObject(PTimestamp.java:32)
> at
> org.apache.phoenix.schema.types.PDataType.toObject(PDataType.java:968)
> at
> org.apache.phoenix.schema.types.PDataType.toObject(PDataType.java:972)
> at
> org.apache.phoenix.schema.types.PDataType.toObject(PDataType.java:1001)
> at
> org.apache.phoenix.schema.types.PDataType.toStringLiteral(PDataType.java:1074)
> at
> org.apache.phoenix.schema.types.PDataType.toStringLiteral(PDataType.java:1070)
> at
> org.apache.phoenix.iterate.ExplainTable.appendPKColumnValue(ExplainTable.java:194)
> at
> org.apache.phoenix.iterate.ExplainTable.appendScanRow(ExplainTable.java:270)
> at
> org.apache.phoenix.iterate.ExplainTable.appendKeyRanges(ExplainTable.java:282)
> at
> org.apache.phoenix.iterate.ExplainTable.explain(ExplainTable.java:125)
> at
> org.apache.phoenix.iterate.BaseResultIterators.explain(BaseResultIterators.java:830)
> at
> org.apache.phoenix.iterate.RoundRobinResultIterator.explain(RoundRobinResultIterator.java:153)
> at
> org.apache.phoenix.execute.BaseQueryPlan.getPlanSteps(BaseQueryPlan.java:468)
> at
> org.apache.phoenix.execute.BaseQueryPlan.iterator(BaseQueryPlan.java:322)
> at
> org.apache.phoenix.execute.BaseQueryPlan.iterator(BaseQueryPlan.java:193)
> at
> org.apache.phoenix.execute.BaseQueryPlan.getExplainPlan(BaseQueryPlan.java:463)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$ExecutableExplainStatement.compilePlan(PhoenixStatement.java:459)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$ExecutableExplainStatement.compilePlan(PhoenixStatement.java:438)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:266)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:261)
> at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:260)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1349)
> at sqlline.Commands.execute(Commands.java:822)
> at sqlline.Commands.sql(Commands.java:732)
> at sqlline.SqlLine.dispatch(SqlLine.java:808)
> at sqlline.SqlLine.begin(SqlLine.java:681)
> at sqlline.SqlLine.start(SqlLine.java:398)
> at sqlline.SqlLine.main(SqlLine.java:292)
> {noformat}
> In this case, down in {{PUnsignedInt$UnsignedIntCodec#decodeInt}}, I see the
> parsed {{v}} is {{-1}}, and the if clause throws.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
