[jira] [Commented] (HIVE-21376) Incompatible change in Hive bucket computation
[ https://issues.apache.org/jira/browse/HIVE-21376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901324#comment-16901324 ] Jesus Camacho Rodriguez commented on HIVE-21376: [~findepi], let's not discuss HDP vs Apache here as I think it is only going to confuse the community since HDP version is not 1:1 match to any Apache version. DM if you have more questions about HDP. > Incompatible change in Hive bucket computation > -- > > Key: HIVE-21376 > URL: https://issues.apache.org/jira/browse/HIVE-21376 > Project: Hive > Issue Type: Bug >Affects Versions: 3.1.0 >Reporter: David Phillips >Assignee: Jesus Camacho Rodriguez >Priority: Major > Fix For: 4.0.0, 3.2.0, 3.1.2 > > Attachments: HIVE-21376.01.patch, HIVE-21376.patch > > > HIVE-20007 seems to have inadvertently changed the bucket hash code > computation via {{ObjectInspectorUtils.getBucketHashCodeOld()}} for the > {{DATE}} and {{TIMESTAMP}} data type2. > {{DATE}} was previously computed using {{DateWritable}}, which uses > {{daysSinceEpoch}} as the hash code. It is now computed using > {{DateWritableV2}}, which uses the hash code of {{java.time.LocalDate}} > (which is not days since epoch). > {{TIMESTAMP}} was previous computed using {{TimestampWritable}} and now uses > {{TimestampWritableV2}}. They ostensibly use the same hash code computation, > but there are two important differences: > # {{TimestampWritable}} rounds the number of milliseconds into the seconds > portion of the computation, but {{TimestampWritableV2}} does not. > # {{TimestampWritable}} gets the epoch time from {{java.sql.Timestamp}}, > which returns it relative to the JVM time zone, not UTC. > {{TimestampWritableV2}} uses a {{LocalDateTime}} relative to UTC. > I was unable to get Hive 3.1 running in order to verify if this actually > causes data to be read or written incorrectly (there may be code above this > library method which makes things work correctly). However, if my > understanding is correct, this means Hive 3.1 is both forwards and backwards > incompatible with bucketed tables using either of these data types. It also > indicates that Hive needs tests to verify that the hash code does not change > between releases. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (HIVE-21376) Incompatible change in Hive bucket computation
[ https://issues.apache.org/jira/browse/HIVE-21376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901291#comment-16901291 ] Piotr Findeisen commented on HIVE-21376: bq. If bucketed data with those types has been written in 3.0 using v2, a user should recreate those bucketed tables using a more recent Hive version. To me that means Hive 3 should not be deployed on production until this issue is fixed. It's fixed in 3.1.2, but the latest available from HDP is 3.1.0. [~jcamachorodriguez] do you have a timeline when 3.1.2 will be available in HDP? > Incompatible change in Hive bucket computation > -- > > Key: HIVE-21376 > URL: https://issues.apache.org/jira/browse/HIVE-21376 > Project: Hive > Issue Type: Bug >Affects Versions: 3.1.0 >Reporter: David Phillips >Assignee: Jesus Camacho Rodriguez >Priority: Major > Fix For: 4.0.0, 3.2.0, 3.1.2 > > Attachments: HIVE-21376.01.patch, HIVE-21376.patch > > > HIVE-20007 seems to have inadvertently changed the bucket hash code > computation via {{ObjectInspectorUtils.getBucketHashCodeOld()}} for the > {{DATE}} and {{TIMESTAMP}} data type2. > {{DATE}} was previously computed using {{DateWritable}}, which uses > {{daysSinceEpoch}} as the hash code. It is now computed using > {{DateWritableV2}}, which uses the hash code of {{java.time.LocalDate}} > (which is not days since epoch). > {{TIMESTAMP}} was previous computed using {{TimestampWritable}} and now uses > {{TimestampWritableV2}}. They ostensibly use the same hash code computation, > but there are two important differences: > # {{TimestampWritable}} rounds the number of milliseconds into the seconds > portion of the computation, but {{TimestampWritableV2}} does not. > # {{TimestampWritable}} gets the epoch time from {{java.sql.Timestamp}}, > which returns it relative to the JVM time zone, not UTC. > {{TimestampWritableV2}} uses a {{LocalDateTime}} relative to UTC. > I was unable to get Hive 3.1 running in order to verify if this actually > causes data to be read or written incorrectly (there may be code above this > library method which makes things work correctly). However, if my > understanding is correct, this means Hive 3.1 is both forwards and backwards > incompatible with bucketed tables using either of these data types. It also > indicates that Hive needs tests to verify that the hash code does not change > between releases. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (HIVE-21376) Incompatible change in Hive bucket computation
[ https://issues.apache.org/jira/browse/HIVE-21376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16787245#comment-16787245 ] Ashutosh Chauhan commented on HIVE-21376: - +1 > Incompatible change in Hive bucket computation > -- > > Key: HIVE-21376 > URL: https://issues.apache.org/jira/browse/HIVE-21376 > Project: Hive > Issue Type: Bug >Affects Versions: 3.1.0 >Reporter: David Phillips >Assignee: Jesus Camacho Rodriguez >Priority: Major > Attachments: HIVE-21376.01.patch, HIVE-21376.patch > > > HIVE-20007 seems to have inadvertently changed the bucket hash code > computation via {{ObjectInspectorUtils.getBucketHashCodeOld()}} for the > {{DATE}} and {{TIMESTAMP}} data type2. > {{DATE}} was previously computed using {{DateWritable}}, which uses > {{daysSinceEpoch}} as the hash code. It is now computed using > {{DateWritableV2}}, which uses the hash code of {{java.time.LocalDate}} > (which is not days since epoch). > {{TIMESTAMP}} was previous computed using {{TimestampWritable}} and now uses > {{TimestampWritableV2}}. They ostensibly use the same hash code computation, > but there are two important differences: > # {{TimestampWritable}} rounds the number of milliseconds into the seconds > portion of the computation, but {{TimestampWritableV2}} does not. > # {{TimestampWritable}} gets the epoch time from {{java.sql.Timestamp}}, > which returns it relative to the JVM time zone, not UTC. > {{TimestampWritableV2}} uses a {{LocalDateTime}} relative to UTC. > I was unable to get Hive 3.1 running in order to verify if this actually > causes data to be read or written incorrectly (there may be code above this > library method which makes things work correctly). However, if my > understanding is correct, this means Hive 3.1 is both forwards and backwards > incompatible with bucketed tables using either of these data types. It also > indicates that Hive needs tests to verify that the hash code does not change > between releases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-21376) Incompatible change in Hive bucket computation
[ https://issues.apache.org/jira/browse/HIVE-21376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785993#comment-16785993 ] Jesus Camacho Rodriguez commented on HIVE-21376: [~ashutoshc], could you take a look? I will create a follow-up to add tests that verify that type hash codes for bucketing do not change between releases so we do not hit this issue again in future. > Incompatible change in Hive bucket computation > -- > > Key: HIVE-21376 > URL: https://issues.apache.org/jira/browse/HIVE-21376 > Project: Hive > Issue Type: Bug >Affects Versions: 3.1.0 >Reporter: David Phillips >Assignee: Jesus Camacho Rodriguez >Priority: Major > Attachments: HIVE-21376.01.patch, HIVE-21376.patch > > > HIVE-20007 seems to have inadvertently changed the bucket hash code > computation via {{ObjectInspectorUtils.getBucketHashCodeOld()}} for the > {{DATE}} and {{TIMESTAMP}} data type2. > {{DATE}} was previously computed using {{DateWritable}}, which uses > {{daysSinceEpoch}} as the hash code. It is now computed using > {{DateWritableV2}}, which uses the hash code of {{java.time.LocalDate}} > (which is not days since epoch). > {{TIMESTAMP}} was previous computed using {{TimestampWritable}} and now uses > {{TimestampWritableV2}}. They ostensibly use the same hash code computation, > but there are two important differences: > # {{TimestampWritable}} rounds the number of milliseconds into the seconds > portion of the computation, but {{TimestampWritableV2}} does not. > # {{TimestampWritable}} gets the epoch time from {{java.sql.Timestamp}}, > which returns it relative to the JVM time zone, not UTC. > {{TimestampWritableV2}} uses a {{LocalDateTime}} relative to UTC. > I was unable to get Hive 3.1 running in order to verify if this actually > causes data to be read or written incorrectly (there may be code above this > library method which makes things work correctly). However, if my > understanding is correct, this means Hive 3.1 is both forwards and backwards > incompatible with bucketed tables using either of these data types. It also > indicates that Hive needs tests to verify that the hash code does not change > between releases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-21376) Incompatible change in Hive bucket computation
[ https://issues.apache.org/jira/browse/HIVE-21376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785380#comment-16785380 ] Hive QA commented on HIVE-21376: Here are the results of testing the latest attachment: https://issues.apache.org/jira/secure/attachment/12961205/HIVE-21376.01.patch {color:green}SUCCESS:{color} +1 due to 1 test(s) being added or modified. {color:green}SUCCESS:{color} +1 due to 15818 tests passed Test results: https://builds.apache.org/job/PreCommit-HIVE-Build/16355/testReport Console output: https://builds.apache.org/job/PreCommit-HIVE-Build/16355/console Test logs: http://104.198.109.242/logs/PreCommit-HIVE-Build-16355/ Messages: {noformat} Executing org.apache.hive.ptest.execution.TestCheckPhase Executing org.apache.hive.ptest.execution.PrepPhase Executing org.apache.hive.ptest.execution.YetusPhase Executing org.apache.hive.ptest.execution.ExecutionPhase Executing org.apache.hive.ptest.execution.ReportingPhase {noformat} This message is automatically generated. ATTACHMENT ID: 12961205 - PreCommit-HIVE-Build > Incompatible change in Hive bucket computation > -- > > Key: HIVE-21376 > URL: https://issues.apache.org/jira/browse/HIVE-21376 > Project: Hive > Issue Type: Bug >Affects Versions: 3.1.0 >Reporter: David Phillips >Assignee: Jesus Camacho Rodriguez >Priority: Major > Attachments: HIVE-21376.01.patch, HIVE-21376.patch > > > HIVE-20007 seems to have inadvertently changed the bucket hash code > computation via {{ObjectInspectorUtils.getBucketHashCodeOld()}} for the > {{DATE}} and {{TIMESTAMP}} data type2. > {{DATE}} was previously computed using {{DateWritable}}, which uses > {{daysSinceEpoch}} as the hash code. It is now computed using > {{DateWritableV2}}, which uses the hash code of {{java.time.LocalDate}} > (which is not days since epoch). > {{TIMESTAMP}} was previous computed using {{TimestampWritable}} and now uses > {{TimestampWritableV2}}. They ostensibly use the same hash code computation, > but there are two important differences: > # {{TimestampWritable}} rounds the number of milliseconds into the seconds > portion of the computation, but {{TimestampWritableV2}} does not. > # {{TimestampWritable}} gets the epoch time from {{java.sql.Timestamp}}, > which returns it relative to the JVM time zone, not UTC. > {{TimestampWritableV2}} uses a {{LocalDateTime}} relative to UTC. > I was unable to get Hive 3.1 running in order to verify if this actually > causes data to be read or written incorrectly (there may be code above this > library method which makes things work correctly). However, if my > understanding is correct, this means Hive 3.1 is both forwards and backwards > incompatible with bucketed tables using either of these data types. It also > indicates that Hive needs tests to verify that the hash code does not change > between releases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-21376) Incompatible change in Hive bucket computation
[ https://issues.apache.org/jira/browse/HIVE-21376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785287#comment-16785287 ] Hive QA commented on HIVE-21376: | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | || || || || {color:brown} master Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m 53s{color} | {color:blue} Maven dependency ordering for branch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 8m 2s{color} | {color:green} master passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 45s{color} | {color:green} master passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 5s{color} | {color:green} master passed {color} | | {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 50s{color} | {color:blue} serde in master has 197 extant Findbugs warnings. {color} | | {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 4m 38s{color} | {color:blue} ql in master has 2251 extant Findbugs warnings. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 27s{color} | {color:green} master passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 30s{color} | {color:blue} Maven dependency ordering for patch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m 10s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 45s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 45s{color} | {color:green} the patch passed {color} | | {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m 18s{color} | {color:red} serde: The patch generated 2 new + 264 unchanged - 0 fixed = 266 total (was 264) {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m 51s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 25s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 15s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 33m 35s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Optional Tests | asflicense javac javadoc findbugs checkstyle compile | | uname | Linux hiveptest-server-upstream 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) x86_64 GNU/Linux | | Build tool | maven | | Personality | /data/hiveptest/working/yetus_PreCommit-HIVE-Build-16355/dev-support/hive-personality.sh | | git revision | master / 9dc28db | | Default Java | 1.8.0_111 | | findbugs | v3.0.0 | | checkstyle | http://104.198.109.242/logs//PreCommit-HIVE-Build-16355/yetus/diff-checkstyle-serde.txt | | modules | C: serde ql U: . | | Console output | http://104.198.109.242/logs//PreCommit-HIVE-Build-16355/yetus.txt | | Powered by | Apache Yetushttp://yetus.apache.org | This message was automatically generated. > Incompatible change in Hive bucket computation > -- > > Key: HIVE-21376 > URL: https://issues.apache.org/jira/browse/HIVE-21376 > Project: Hive > Issue Type: Bug >Affects Versions: 3.1.0 >Reporter: David Phillips >Assignee: Jesus Camacho Rodriguez >Priority: Major > Attachments: HIVE-21376.01.patch, HIVE-21376.patch > > > HIVE-20007 seems to have inadvertently changed the bucket hash code > computation via {{ObjectInspectorUtils.getBucketHashCodeOld()}} for the > {{DATE}} and {{TIMESTAMP}} data type2. > {{DATE}} was previously computed using {{DateWritable}}, which uses > {{daysSinceEpoch}} as the hash code. It is now computed using > {{DateWritableV2}}, which uses the hash code of {{java.time.LocalDate}} > (which is not days since epoch). > {{TIMESTAMP}} was previous computed using {{TimestampWritable}} and now uses > {{TimestampWritableV2}}. They ostensibly use the same hash code computation, > but there are two important differences:
[jira] [Commented] (HIVE-21376) Incompatible change in Hive bucket computation
[ https://issues.apache.org/jira/browse/HIVE-21376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16783826#comment-16783826 ] Hive QA commented on HIVE-21376: Here are the results of testing the latest attachment: https://issues.apache.org/jira/secure/attachment/12961024/HIVE-21376.patch {color:green}SUCCESS:{color} +1 due to 1 test(s) being added or modified. {color:red}ERROR:{color} -1 due to 18 failed/errored test(s), 15819 tests executed *Failed tests:* {noformat} org.apache.hadoop.hive.cli.TestCliDriver.testCliDriver[orc_merge12] (batchId=68) org.apache.hadoop.hive.cli.TestCliDriver.testCliDriver[orc_ppd_char] (batchId=11) org.apache.hadoop.hive.cli.TestCliDriver.testCliDriver[vector_binary_join_groupby] (batchId=88) org.apache.hadoop.hive.cli.TestCliDriver.testCliDriver[vector_data_types] (batchId=83) org.apache.hadoop.hive.cli.TestCliDriver.testCliDriver[vector_decimal_expressions] (batchId=57) org.apache.hadoop.hive.cli.TestMiniLlapLocalCliDriver.testCliDriver[llap_uncompressed] (batchId=175) org.apache.hadoop.hive.cli.TestMiniLlapLocalCliDriver.testCliDriver[orc_llap] (batchId=171) org.apache.hadoop.hive.cli.TestMiniLlapLocalCliDriver.testCliDriver[orc_ppd_date] (batchId=171) org.apache.hadoop.hive.cli.TestMiniLlapLocalCliDriver.testCliDriver[orc_ppd_decimal] (batchId=160) org.apache.hadoop.hive.cli.TestMiniLlapLocalCliDriver.testCliDriver[orc_ppd_timestamp] (batchId=181) org.apache.hadoop.hive.cli.TestMiniLlapLocalCliDriver.testCliDriver[orc_ppd_varchar] (batchId=178) org.apache.hadoop.hive.cli.TestMiniLlapLocalCliDriver.testCliDriver[vector_binary_join_groupby] (batchId=181) org.apache.hadoop.hive.cli.TestMiniLlapLocalCliDriver.testCliDriver[vector_data_types] (batchId=180) org.apache.hadoop.hive.cli.TestMiniLlapLocalCliDriver.testCliDriver[vector_decimal_expressions] (batchId=174) org.apache.hadoop.hive.cli.TestMiniTezCliDriver.testCliDriver[orc_merge12] (batchId=110) org.apache.hadoop.hive.cli.TestSparkCliDriver.testCliDriver[vector_data_types] (batchId=146) org.apache.hive.jdbc.TestJdbcWithMiniLlapArrow.testComplexQuery (batchId=263) org.apache.hive.jdbc.TestJdbcWithMiniLlapArrow.testKillQuery (batchId=263) {noformat} Test results: https://builds.apache.org/job/PreCommit-HIVE-Build/16329/testReport Console output: https://builds.apache.org/job/PreCommit-HIVE-Build/16329/console Test logs: http://104.198.109.242/logs/PreCommit-HIVE-Build-16329/ Messages: {noformat} Executing org.apache.hive.ptest.execution.TestCheckPhase Executing org.apache.hive.ptest.execution.PrepPhase Executing org.apache.hive.ptest.execution.YetusPhase Executing org.apache.hive.ptest.execution.ExecutionPhase Executing org.apache.hive.ptest.execution.ReportingPhase Tests exited with: TestsFailedException: 18 tests failed {noformat} This message is automatically generated. ATTACHMENT ID: 12961024 - PreCommit-HIVE-Build > Incompatible change in Hive bucket computation > -- > > Key: HIVE-21376 > URL: https://issues.apache.org/jira/browse/HIVE-21376 > Project: Hive > Issue Type: Bug >Affects Versions: 3.1.0 >Reporter: David Phillips >Assignee: Jesus Camacho Rodriguez >Priority: Major > Attachments: HIVE-21376.patch > > > HIVE-20007 seems to have inadvertently changed the bucket hash code > computation via {{ObjectInspectorUtils.getBucketHashCodeOld()}} for the > {{DATE}} and {{TIMESTAMP}} data type2. > {{DATE}} was previously computed using {{DateWritable}}, which uses > {{daysSinceEpoch}} as the hash code. It is now computed using > {{DateWritableV2}}, which uses the hash code of {{java.time.LocalDate}} > (which is not days since epoch). > {{TIMESTAMP}} was previous computed using {{TimestampWritable}} and now uses > {{TimestampWritableV2}}. They ostensibly use the same hash code computation, > but there are two important differences: > # {{TimestampWritable}} rounds the number of milliseconds into the seconds > portion of the computation, but {{TimestampWritableV2}} does not. > # {{TimestampWritable}} gets the epoch time from {{java.sql.Timestamp}}, > which returns it relative to the JVM time zone, not UTC. > {{TimestampWritableV2}} uses a {{LocalDateTime}} relative to UTC. > I was unable to get Hive 3.1 running in order to verify if this actually > causes data to be read or written incorrectly (there may be code above this > library method which makes things work correctly). However, if my > understanding is correct, this means Hive 3.1 is both forwards and backwards > incompatible with bucketed tables using either of these data types. It also > indicates that Hive needs tests to verify that the hash code does not change > between releases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-21376) Incompatible change in Hive bucket computation
[ https://issues.apache.org/jira/browse/HIVE-21376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16783781#comment-16783781 ] Hive QA commented on HIVE-21376: | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | || || || || {color:brown} master Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 9m 19s{color} | {color:green} master passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 20s{color} | {color:green} master passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 19s{color} | {color:green} master passed {color} | | {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 47s{color} | {color:blue} serde in master has 197 extant Findbugs warnings. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 18s{color} | {color:green} master passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 23s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 21s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 21s{color} | {color:green} the patch passed {color} | | {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m 18s{color} | {color:red} serde: The patch generated 2 new + 264 unchanged - 0 fixed = 266 total (was 264) {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m 57s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 18s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 15s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 14m 13s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Optional Tests | asflicense javac javadoc findbugs checkstyle compile | | uname | Linux hiveptest-server-upstream 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) x86_64 GNU/Linux | | Build tool | maven | | Personality | /data/hiveptest/working/yetus_PreCommit-HIVE-Build-16329/dev-support/hive-personality.sh | | git revision | master / de61102 | | Default Java | 1.8.0_111 | | findbugs | v3.0.0 | | checkstyle | http://104.198.109.242/logs//PreCommit-HIVE-Build-16329/yetus/diff-checkstyle-serde.txt | | modules | C: serde U: serde | | Console output | http://104.198.109.242/logs//PreCommit-HIVE-Build-16329/yetus.txt | | Powered by | Apache Yetushttp://yetus.apache.org | This message was automatically generated. > Incompatible change in Hive bucket computation > -- > > Key: HIVE-21376 > URL: https://issues.apache.org/jira/browse/HIVE-21376 > Project: Hive > Issue Type: Bug >Affects Versions: 3.1.0 >Reporter: David Phillips >Assignee: Jesus Camacho Rodriguez >Priority: Major > Attachments: HIVE-21376.patch > > > HIVE-20007 seems to have inadvertently changed the bucket hash code > computation via {{ObjectInspectorUtils.getBucketHashCodeOld()}} for the > {{DATE}} and {{TIMESTAMP}} data type2. > {{DATE}} was previously computed using {{DateWritable}}, which uses > {{daysSinceEpoch}} as the hash code. It is now computed using > {{DateWritableV2}}, which uses the hash code of {{java.time.LocalDate}} > (which is not days since epoch). > {{TIMESTAMP}} was previous computed using {{TimestampWritable}} and now uses > {{TimestampWritableV2}}. They ostensibly use the same hash code computation, > but there are two important differences: > # {{TimestampWritable}} rounds the number of milliseconds into the seconds > portion of the computation, but {{TimestampWritableV2}} does not. > # {{TimestampWritable}} gets the epoch time from {{java.sql.Timestamp}}, > which returns it relative to the JVM time zone, not UTC. > {{TimestampWritableV2}} uses a {{LocalDateTime}} relative to UTC. > I was unable to get Hive 3.1 running in order to verify if this actually > causes data to be read or written
[jira] [Commented] (HIVE-21376) Incompatible change in Hive bucket computation
[ https://issues.apache.org/jira/browse/HIVE-21376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16783741#comment-16783741 ] Jesus Camacho Rodriguez commented on HIVE-21376: That is correct. I believe the 3.0 -> 3.1 timestamp incompatibility is difficult to fix as internal representation changed precisely to fix timezone related issues. I hope HIVE-20007 had gone in 3.0 as I initially thought, then incompatibility would be v1 vs v2 (modulo this fix), but it did not make the cut on time. If bucketed data with those types has been written in 3.0 using v2, a user should recreate those bucketed tables using a more recent Hive version. > Incompatible change in Hive bucket computation > -- > > Key: HIVE-21376 > URL: https://issues.apache.org/jira/browse/HIVE-21376 > Project: Hive > Issue Type: Bug >Affects Versions: 3.1.0 >Reporter: David Phillips >Assignee: Jesus Camacho Rodriguez >Priority: Major > Attachments: HIVE-21376.patch > > > HIVE-20007 seems to have inadvertently changed the bucket hash code > computation via {{ObjectInspectorUtils.getBucketHashCodeOld()}} for the > {{DATE}} and {{TIMESTAMP}} data type2. > {{DATE}} was previously computed using {{DateWritable}}, which uses > {{daysSinceEpoch}} as the hash code. It is now computed using > {{DateWritableV2}}, which uses the hash code of {{java.time.LocalDate}} > (which is not days since epoch). > {{TIMESTAMP}} was previous computed using {{TimestampWritable}} and now uses > {{TimestampWritableV2}}. They ostensibly use the same hash code computation, > but there are two important differences: > # {{TimestampWritable}} rounds the number of milliseconds into the seconds > portion of the computation, but {{TimestampWritableV2}} does not. > # {{TimestampWritable}} gets the epoch time from {{java.sql.Timestamp}}, > which returns it relative to the JVM time zone, not UTC. > {{TimestampWritableV2}} uses a {{LocalDateTime}} relative to UTC. > I was unable to get Hive 3.1 running in order to verify if this actually > causes data to be read or written incorrectly (there may be code above this > library method which makes things work correctly). However, if my > understanding is correct, this means Hive 3.1 is both forwards and backwards > incompatible with bucketed tables using either of these data types. It also > indicates that Hive needs tests to verify that the hash code does not change > between releases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-21376) Incompatible change in Hive bucket computation
[ https://issues.apache.org/jira/browse/HIVE-21376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16783706#comment-16783706 ] David Phillips commented on HIVE-21376: --- I believe that v2 will have a similar incompatible change between 3.0 and 3.1 for {{TIMESTAMP}} due to the time value coming from {{java.sql.Timestamp}} changing from local to UTC. > Incompatible change in Hive bucket computation > -- > > Key: HIVE-21376 > URL: https://issues.apache.org/jira/browse/HIVE-21376 > Project: Hive > Issue Type: Bug >Affects Versions: 3.1.0 >Reporter: David Phillips >Assignee: Jesus Camacho Rodriguez >Priority: Major > Attachments: HIVE-21376.patch > > > HIVE-20007 seems to have inadvertently changed the bucket hash code > computation via {{ObjectInspectorUtils.getBucketHashCodeOld()}} for the > {{DATE}} and {{TIMESTAMP}} data type2. > {{DATE}} was previously computed using {{DateWritable}}, which uses > {{daysSinceEpoch}} as the hash code. It is now computed using > {{DateWritableV2}}, which uses the hash code of {{java.time.LocalDate}} > (which is not days since epoch). > {{TIMESTAMP}} was previous computed using {{TimestampWritable}} and now uses > {{TimestampWritableV2}}. They ostensibly use the same hash code computation, > but there are two important differences: > # {{TimestampWritable}} rounds the number of milliseconds into the seconds > portion of the computation, but {{TimestampWritableV2}} does not. > # {{TimestampWritable}} gets the epoch time from {{java.sql.Timestamp}}, > which returns it relative to the JVM time zone, not UTC. > {{TimestampWritableV2}} uses a {{LocalDateTime}} relative to UTC. > I was unable to get Hive 3.1 running in order to verify if this actually > causes data to be read or written incorrectly (there may be code above this > library method which makes things work correctly). However, if my > understanding is correct, this means Hive 3.1 is both forwards and backwards > incompatible with bucketed tables using either of these data types. It also > indicates that Hive needs tests to verify that the hash code does not change > between releases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-21376) Incompatible change in Hive bucket computation
[ https://issues.apache.org/jira/browse/HIVE-21376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16782879#comment-16782879 ] Jesus Camacho Rodriguez commented on HIVE-21376: Thanks for reporting this [~electrum]. Indeed this should be an issue with versions >= 3.1. I believe this also means that old implementation could lead to data ending up in wrong buckets when users were reading/writing in different time zones. There is a bucketing version property associated with tables that is used to keep backwards compatibility introduced in HIVE-18910. Only two versions exist at this time, v1 and v2, each of them using different hash functions. v1 relies on {{getBucketHashCodeOld}} as you mention. {{getBucketHashCodeOld}} should be changed so v1 can compute hashcode for {{Date}} and {{Timestamp}} values as it used to do. I think v2 can remain unchanged. > Incompatible change in Hive bucket computation > -- > > Key: HIVE-21376 > URL: https://issues.apache.org/jira/browse/HIVE-21376 > Project: Hive > Issue Type: Bug >Affects Versions: 3.1.0 >Reporter: David Phillips >Priority: Major > > HIVE-20007 seems to have inadvertently changed the bucket hash code > computation via {{ObjectInspectorUtils.getBucketHashCodeOld()}} for the > {{DATE}} and {{TIMESTAMP}} data type2. > {{DATE}} was previously computed using {{DateWritable}}, which uses > {{daysSinceEpoch}} as the hash code. It is now computed using > {{DateWritableV2}}, which uses the hash code of {{java.time.LocalDate}} > (which is not days since epoch). > {{TIMESTAMP}} was previous computed using {{TimestampWritable}} and now uses > {{TimestampWritableV2}}. They ostensibly use the same hash code computation, > but there are two important differences: > # {{TimestampWritable}} rounds the number of milliseconds into the seconds > portion of the computation, but {{TimestampWritableV2}} does not. > # {{TimestampWritable}} gets the epoch time from {{java.sql.Timestamp}}, > which returns it relative to the JVM time zone, not UTC. > {{TimestampWritableV2}} uses a {{LocalDateTime}} relative to UTC. > I was unable to get Hive 3.1 running in order to verify if this actually > causes data to be read or written incorrectly (there may be code above this > library method which makes things work correctly). However, if my > understanding is correct, this means Hive 3.1 is both forwards and backwards > incompatible with bucketed tables using either of these data types. It also > indicates that Hive needs tests to verify that the hash code does not change > between releases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)