[
https://issues.apache.org/jira/browse/PHOENIX-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15148140#comment-15148140
]
Sergey Soldatov commented on PHOENIX-2631:
------------------------------------------
There is no strange behavior. This is how java.sql.Timestamp works. It keeps
integral seconds in the date value and fraction of second in the nanos. So,
when the test calls setNanos it overrides fraction of seconds. What makes me
worry is the in PTimestamp.toObject:
v.setNanos(nanosDeserialized < 1000000 ? v.getNanos() + nanosDeserialized
: nanosDeserialized);
This is a potential problem that nanosDeserialized will be greater than
999999999 or less than zero after it was previously inverted, but still has ASC
order. Not sure whether it could happen in regular routine.
> 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)
