[
https://issues.apache.org/jira/browse/PHOENIX-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15474738#comment-15474738
]
Hadoop QA commented on PHOENIX-2946:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12827618/PHOENIX-2946_v6.patch
against master branch at commit 3a8724eee05aaf477bf6085415e781856990e1c0.
ATTACHMENT ID: 12827618
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated
34 warning messages.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+ private void setTimestampParameter(int parameterIndex, Timestamp x,
Calendar cal) throws SQLException {
+ // Ignore trailing zero bytes if fixed byte length (for
example TIMESTAMP compared to DATE)
+ if (lhsLength != rhsLength && this.isFixedWidth() &&
rhsType.isFixedWidth() && this.getByteSize() != null && rhsType.getByteSize()
!= null) {
+ for (int i = lhsOffset + lhsLength - 1; i >= minOffset
&& lhsSortOrder.normalize(lhs[i]) == 0; i--,lhsLength--) {
+ for (int i = rhsOffset + rhsLength - 1; i >= minOffset
&& rhsSortOrder.normalize(rhs[i]) == 0; i--,rhsLength--) {
+ new DateCodec(), 11); // After TIMESTAMP and DATE to ensure
toLiteral finds those first
+ public Date toObject(byte[] b, int o, int l, PDataType actualType,
SortOrder sortOrder, Integer maxLength, Integer scale) {
+ return equalsAny(targetType, PDate.INSTANCE, PTime.INSTANCE,
PTimestamp.INSTANCE, PVarbinary.INSTANCE, PBinary.INSTANCE);
+ return super.isBytesComparableWith(otherType) || otherType ==
PTime.INSTANCE || otherType == PTimestamp.INSTANCE || otherType ==
PLong.INSTANCE;
+ Integer maxLength, Integer scale, SortOrder actualModifier,
Integer desiredMaxLength, Integer desiredScale,
{color:red}-1 core tests{color}. The patch failed these unit tests:
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/559//testReport/
Javadoc warnings:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/559//artifact/patchprocess/patchJavadocWarnings.txt
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/559//console
This message is automatically generated.
> Projected comparison between date and timestamp columns always returns true
> ---------------------------------------------------------------------------
>
> Key: PHOENIX-2946
> URL: https://issues.apache.org/jira/browse/PHOENIX-2946
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.6.0, 4.8.0
> Reporter: Kevin Liew
> Assignee: James Taylor
> Priority: Minor
> Labels: comparison, date, timestamp
> Fix For: 4.9.0, 4.8.1
>
> Attachments: PHOENIX-2946_v2.patch, PHOENIX-2946_v3.patch,
> PHOENIX-2946_v4.patch, PHOENIX-2946_v5.patch, PHOENIX-2946_v6.patch
>
>
> {code}
> 0: jdbc:phoenix:thin:url=http://localhost:876> create table test (dateCol
> DATE primary key, timestampCol TIMESTAMP);
> No rows affected (2.559 seconds)
> 0: jdbc:phoenix:thin:url=http://localhost:876> upsert into test values
> (TO_DATE('1990-01-01'), NOW());
> 1 row affected (0.255 seconds)
> 0: jdbc:phoenix:thin:url=http://localhost:876> select dateCol = timestampCol
> from test;
> +------------------------------------------+
> | DATECOL = TIMESTAMPCOL |
> +------------------------------------------+
> | true |
> +------------------------------------------+
> 1 row selected (0.019 seconds)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
