[ 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)