[jira] [Updated] (HIVE-19488) enable CM root based on db parameter, identifying a db as source of replication.

2018-05-13 Thread mahesh kumar behera (JIRA)

 [ 
https://issues.apache.org/jira/browse/HIVE-19488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

mahesh kumar behera updated HIVE-19488:
---
Attachment: (was: HIVE-19488.02.patch)

> enable CM root based on db parameter, identifying a db as source of 
> replication.
> 
>
> Key: HIVE-19488
> URL: https://issues.apache.org/jira/browse/HIVE-19488
> Project: Hive
>  Issue Type: Task
>  Components: Hive, HiveServer2, repl
>Affects Versions: 3.1.0
>Reporter: mahesh kumar behera
>Assignee: mahesh kumar behera
>Priority: Major
>  Labels: pull-request-available
> Fix For: 3.1.0
>
> Attachments: HIVE-19488.01.patch, HIVE-19488.02.patch
>
>
> * add a parameter at db level to identify if its a source of replication. 
> beacon will set this.
>  * Enable CM root only for databases that are a source of a replication 
> policy, for other db's skip the CM root functionality.
>  * prevent database drop if the parameter indicating its source of a 
> replication, is set.
>  * as an upgrade to this version, beacon should set the property on all 
> existing database policies, in affect.
>  * the parameter should be of the form . –  repl.source.for : List < policy 
> ids >



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HIVE-19488) enable CM root based on db parameter, identifying a db as source of replication.

2018-05-13 Thread mahesh kumar behera (JIRA)

 [ 
https://issues.apache.org/jira/browse/HIVE-19488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

mahesh kumar behera updated HIVE-19488:
---
Attachment: HIVE-19488.02.patch

> enable CM root based on db parameter, identifying a db as source of 
> replication.
> 
>
> Key: HIVE-19488
> URL: https://issues.apache.org/jira/browse/HIVE-19488
> Project: Hive
>  Issue Type: Task
>  Components: Hive, HiveServer2, repl
>Affects Versions: 3.1.0
>Reporter: mahesh kumar behera
>Assignee: mahesh kumar behera
>Priority: Major
>  Labels: pull-request-available
> Fix For: 3.1.0
>
> Attachments: HIVE-19488.01.patch, HIVE-19488.02.patch
>
>
> * add a parameter at db level to identify if its a source of replication. 
> beacon will set this.
>  * Enable CM root only for databases that are a source of a replication 
> policy, for other db's skip the CM root functionality.
>  * prevent database drop if the parameter indicating its source of a 
> replication, is set.
>  * as an upgrade to this version, beacon should set the property on all 
> existing database policies, in affect.
>  * the parameter should be of the form . –  repl.source.for : List < policy 
> ids >



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HIVE-19382) Acquire locks before generating valid transaction list for some operations

2018-05-13 Thread Hive QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HIVE-19382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16473403#comment-16473403
 ] 

Hive QA commented on HIVE-19382:


| (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}  7m 
24s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m  
1s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
39s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue}  3m 
45s{color} | {color:blue} ql in master has 2321 extant Findbugs warnings. 
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
55s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  1m 
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m  
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m  
3s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red}  0m 
37s{color} | {color:red} ql: The patch generated 17 new + 170 unchanged - 6 
fixed = 187 total (was 176) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red}  4m  
1s{color} | {color:red} ql generated 1 new + 2321 unchanged - 0 fixed = 2322 
total (was 2321) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
55s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
13s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 22m 15s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:ql |
|  |  Redundant nullcheck of txnWriteIdList, which is known to be non-null in 
org.apache.hadoop.hive.ql.Driver.isValidTxnListState()  Redundant null check at 
Driver.java:is known to be non-null in 
org.apache.hadoop.hive.ql.Driver.isValidTxnListState()  Redundant null check at 
Driver.java:[line 916] |
\\
\\
|| 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-10891/dev-support/hive-personality.sh
 |
| git revision | master / 6f9368b |
| Default Java | 1.8.0_111 |
| findbugs | v3.0.0 |
| checkstyle | 
http://104.198.109.242/logs//PreCommit-HIVE-Build-10891/yetus/diff-checkstyle-ql.txt
 |
| findbugs | 
http://104.198.109.242/logs//PreCommit-HIVE-Build-10891/yetus/new-findbugs-ql.html
 |
| modules | C: ql U: ql |
| Console output | 
http://104.198.109.242/logs//PreCommit-HIVE-Build-10891/yetus.txt |
| Powered by | Apache Yetushttp://yetus.apache.org |


This message was automatically generated.



> Acquire locks before generating valid transaction list for some operations
> --
>
> Key: HIVE-19382
> URL: https://issues.apache.org/jira/browse/HIVE-19382
> Project: Hive
>  Issue Type: Bug
>  Components: Transactions
>Affects Versions: 3.0.0
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Major
> Attachments: HIVE-19382.01.patch, HIVE-19382.02.patch, 
> HIVE-19382.03.patch, HIVE-19382.patch
>
>
> To ensure correctness, in particular for operations that require exclusive 
> ({{INSERT OVERWRITE}}) and semishared ({{UPDATE}}/{{DELETE}}) locks.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HIVE-19490) Locking on Insert into for non native and managed tables.

2018-05-13 Thread Hive QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HIVE-19490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16473397#comment-16473397
 ] 

Hive QA commented on HIVE-19490:




Here are the results of testing the latest attachment:
https://issues.apache.org/jira/secure/attachment/12923088/HIVE-19490.2.patch

{color:red}ERROR:{color} -1 due to build exiting with an error

Test results: 
https://builds.apache.org/job/PreCommit-HIVE-Build/10889/testReport
Console output: https://builds.apache.org/job/PreCommit-HIVE-Build/10889/console
Test logs: http://104.198.109.242/logs/PreCommit-HIVE-Build-10889/

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
Tests exited with: ExecutionException: java.util.concurrent.ExecutionException: 
org.apache.hive.ptest.execution.ssh.SSHExecutionException: RSyncResult 
[localFile=/data/hiveptest/logs/PreCommit-HIVE-Build-10889/succeeded/221_UTBatch_service_8_tests,
 remoteFile=/home/hiveptest/35.225.119.98-hiveptest-2/logs/, getExitCode()=255, 
getException()=null, getUser()=hiveptest, getHost()=35.225.119.98, 
getInstance()=2]: 'Warning: Permanently added '35.225.119.98' (ECDSA) to the 
list of known hosts.
receiving incremental file list
./
TEST-221_UTBatch_service_8_tests-TEST-org.apache.hive.service.auth.TestLdapAtnProviderWithMiniDS.xml

  0   0%0.00kB/s0:00:00  
 93,274 100%1.31MB/s0:00:00 (xfr#1, to-chk=12/14)
TEST-221_UTBatch_service_8_tests-TEST-org.apache.hive.service.auth.ldap.TestCustomQueryFilter.xml

  0   0%0.00kB/s0:00:00  
 89,239 100%1.23MB/s0:00:00 (xfr#2, to-chk=11/14)
TEST-221_UTBatch_service_8_tests-TEST-org.apache.hive.service.auth.ldap.TestQuery.xml

  0   0%0.00kB/s0:00:00  
 89,224 100%  854.24kB/s0:00:00 (xfr#3, to-chk=10/14)
TEST-221_UTBatch_service_8_tests-TEST-org.apache.hive.service.auth.ldap.TestUserFilter.xml

  0   0%0.00kB/s0:00:00  
 89,213 100%  845.85kB/s0:00:00 (xfr#4, to-chk=9/14)
TEST-221_UTBatch_service_8_tests-TEST-org.apache.hive.service.auth.ldap.TestUserSearchFilter.xml

  0   0%0.00kB/s0:00:00  
 89,650 100%  634.41kB/s0:00:00 (xfr#5, to-chk=8/14)
TEST-221_UTBatch_service_8_tests-TEST-org.apache.hive.service.cli.TestCLIServiceConnectionLimits.xml

  0   0%0.00kB/s0:00:00  
 90,521 100%  635.97kB/s0:00:00 (xfr#6, to-chk=7/14)
TEST-221_UTBatch_service_8_tests-TEST-org.apache.hive.service.cli.TestCLIServiceRestore.xml

  0   0%0.00kB/s0:00:00  
 88,990 100%  625.21kB/s0:00:00 (xfr#7, to-chk=6/14)
TEST-221_UTBatch_service_8_tests-TEST-org.apache.hive.service.cli.TestHiveSQLException.xml

  0   0%0.00kB/s0:00:00  
 89,735 100%  625.94kB/s0:00:00 (xfr#8, to-chk=5/14)
maven-test.txt

  0   0%0.00kB/s0:00:00  
  5,969 100%   41.64kB/s0:00:00 (xfr#9, to-chk=4/14)
logs/
logs/derby.log

  0   0%0.00kB/s0:00:00  
985 100%6.87kB/s0:00:00 (xfr#10, to-chk=1/14)
logs/hive.log

  0   0%0.00kB/s0:00:00  
 42,434,560   1%   40.47MB/s0:01:41  
 99,123,200   2%   47.24MB/s0:01:25  
154,894,336   3%   49.24MB/s0:01:20  
210,042,880   4%   49.99MB/s0:01:18  
266,403,840   6%   53.31MB/s0:01:12  
322,830,336   7%   53.28MB/s0:01:11  
373,555,200   8%   52.08MB/s0:01:12  
417,169,408   9%   49.41MB/s0:01:15  
464,912,384  10%   47.33MB/s0:01:17  
515,833,856  12%   46.02MB/s0:01:18  
568,655,872  13%   46.52MB/s0:01:16  
622,854,144  14%   49.04MB/s0:01:11  
678,068,224  16%   50.78MB/s0:01:08  
734,887,936  17%   52.20MB/s0:01:05  
791,707,648  18%   53.17MB/s0:01:03  
848,527,360  20%   53.75MB/s0:01:01  
905,969,664  21%   54.34MB/s0:00:59  
963,510,272  22%   54.48MB/s0:00:58  
  1,021,083,648  24%   54.66MB/s0:00:57  
  1,071,841,280  25%   53.24MB/s0:00:57  
  1,120,927,744  26%   51.25MB/s0:00:59  
  1,177,026,560  27%   49.17MB/s0:01:00  
  1,234,239,488  29%   49.09MB/s0:00:59  
  1,275,068,416  30%   45.34MB/s0:01:03  
  1,326,972,928  31%   45.64MB/s0:01:02  
  1,385,332,736  32%   47.73MB/s0:00:58  
  1,419,509,760  33%   41.53MB/s0:01:06  
  1,448,083,456  34%   39.26MB/s0:01:09  
  1,486,880,768  35%   35.98MB/s0:01:14  
  1,532,231,680  36%   33.05MB/s0:01:19  
  1,579,188,224  37%   36.48MB/s0:01:10  
  1,627,947,008  38%   41.95MB/s0:01:00  
  1,674,313,728  39%   43.24MB/s0:00:57  
  1,729,953,792  40%   45.60MB/s0:00:53  
  1,786,970,112  42%   

[jira] [Commented] (HIVE-19435) Incremental replication cause data loss if a table is dropped followed by create and insert-into with different partition type.

2018-05-13 Thread Sankar Hariappan (JIRA)

[ 
https://issues.apache.org/jira/browse/HIVE-19435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16473396#comment-16473396
 ] 

Sankar Hariappan commented on HIVE-19435:
-

Test failures are irrelevant.

Patch committed to branch-3.

> Incremental replication cause data loss if a table is dropped followed by 
> create and insert-into with different partition type.
> ---
>
> Key: HIVE-19435
> URL: https://issues.apache.org/jira/browse/HIVE-19435
> Project: Hive
>  Issue Type: Bug
>  Components: HiveServer2, repl
>Affects Versions: 3.0.0
>Reporter: Sankar Hariappan
>Assignee: Sankar Hariappan
>Priority: Major
>  Labels: DR, pull-request-available, replication
> Fix For: 3.0.0, 3.1.0
>
> Attachments: HIVE-19435.01-branch-3.patch, HIVE-19435.01.patch, 
> HIVE-19435.02.patch, HIVE-19435.03.patch
>
>
> If the incremental dump have drop of partitioned table followed by 
> create/insert on non-partitioned table with same name, doesn't replicate the 
> data. Explained below.
> Let's say we have a partitioned table T1 which was already replicated to 
> target.
> DROP_TABLE(T1)->CREATE_TABLE(T1) (Non-partitioned) -> INSERT(T1)(10) 
> After REPL LOAD, T1 doesn't have any data.
> Same is valid for non-partitioned to partitioned and partition spec mismatch 
> case as well.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HIVE-19435) Incremental replication cause data loss if a table is dropped followed by create and insert-into with different partition type.

2018-05-13 Thread Sankar Hariappan (JIRA)

 [ 
https://issues.apache.org/jira/browse/HIVE-19435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sankar Hariappan updated HIVE-19435:

Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Incremental replication cause data loss if a table is dropped followed by 
> create and insert-into with different partition type.
> ---
>
> Key: HIVE-19435
> URL: https://issues.apache.org/jira/browse/HIVE-19435
> Project: Hive
>  Issue Type: Bug
>  Components: HiveServer2, repl
>Affects Versions: 3.0.0
>Reporter: Sankar Hariappan
>Assignee: Sankar Hariappan
>Priority: Major
>  Labels: DR, pull-request-available, replication
> Fix For: 3.0.0, 3.1.0
>
> Attachments: HIVE-19435.01-branch-3.patch, HIVE-19435.01.patch, 
> HIVE-19435.02.patch, HIVE-19435.03.patch
>
>
> If the incremental dump have drop of partitioned table followed by 
> create/insert on non-partitioned table with same name, doesn't replicate the 
> data. Explained below.
> Let's say we have a partitioned table T1 which was already replicated to 
> target.
> DROP_TABLE(T1)->CREATE_TABLE(T1) (Non-partitioned) -> INSERT(T1)(10) 
> After REPL LOAD, T1 doesn't have any data.
> Same is valid for non-partitioned to partitioned and partition spec mismatch 
> case as well.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HIVE-19490) Locking on Insert into for non native and managed tables.

2018-05-13 Thread Hive QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HIVE-19490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16473394#comment-16473394
 ] 

Hive QA commented on HIVE-19490:


| (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}  7m 
46s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m  
0s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
42s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue}  4m  
4s{color} | {color:blue} ql in master has 2321 extant Findbugs warnings. 
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
56s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  1m 
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m  
1s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m  
1s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red}  0m 
44s{color} | {color:red} ql: The patch generated 20 new + 636 unchanged - 8 
fixed = 656 total (was 644) {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}  3m 
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
53s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
13s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 23m  2s{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-10889/dev-support/hive-personality.sh
 |
| git revision | master / 6f9368b |
| Default Java | 1.8.0_111 |
| findbugs | v3.0.0 |
| checkstyle | 
http://104.198.109.242/logs//PreCommit-HIVE-Build-10889/yetus/diff-checkstyle-ql.txt
 |
| modules | C: ql U: ql |
| Console output | 
http://104.198.109.242/logs//PreCommit-HIVE-Build-10889/yetus.txt |
| Powered by | Apache Yetushttp://yetus.apache.org |


This message was automatically generated.



> Locking on Insert into for non native and managed tables.
> -
>
> Key: HIVE-19490
> URL: https://issues.apache.org/jira/browse/HIVE-19490
> Project: Hive
>  Issue Type: Improvement
>  Components: Druid integration
>Reporter: slim bouguerra
>Assignee: slim bouguerra
>Priority: Major
>  Labels: druid, locking
> Attachments: HIVE-19490.2.patch, HIVE-19490.patch
>
>
> Current state of the art: 
> Managed non native table like Druid Tables, will need to get a Lock on Insert 
> into or insert Over write. The nature of this lock is set to Exclusive by 
> default for any non native table.
> This implies that Inserts into Druid table will Lock any read query as well 
> during the execution of the insert into. IMO this lock (on insert into) is  
> not needed since the insert statement is appending data and the state of 
> loading it is managed partially by Hive Storage handler hook and part of it 
> by Druid. 
> What i am proposing is to relax the lock level to shared for all non native 
> tables on insert into operations and keep it as Exclusive Write for insert 
> Overwrite for now.
>  
> Any feedback is welcome.
> cc [~ekoifman] / [~ashutoshc] / [~jdere] / [~hagleitn]
> Also am not sure what is the best way to unit test this currently am using 
> debugger to check if locks are what i except, please let me know if there is 
> a better way to do this. 
>  



--
This message was 

[jira] [Commented] (HIVE-19474) Decimal type should be casted as part of the CTAS or INSERT Clause.

2018-05-13 Thread Ashutosh Chauhan (JIRA)

[ 
https://issues.apache.org/jira/browse/HIVE-19474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16473390#comment-16473390
 ] 

Ashutosh Chauhan commented on HIVE-19474:
-

+1 I agree it doesnt make sense to declare a column as decimal which actually 
is stored as double.

> Decimal type should be casted as part of the CTAS or INSERT Clause.
> ---
>
> Key: HIVE-19474
> URL: https://issues.apache.org/jira/browse/HIVE-19474
> Project: Hive
>  Issue Type: Bug
>  Components: Druid integration
>Reporter: slim bouguerra
>Assignee: slim bouguerra
>Priority: Major
>  Labels: druid
> Fix For: 3.0.0
>
> Attachments: HIVE-19474.patch
>
>
> HIVE-18569  introduced a runtime config variable to allow the indexing of 
> Decimal as Double, this leads to kind of messy state, Hive metadata think the 
> column is still decimal while it is stored as double. Since the Hive metadata 
> of the column is Decimal the logical optimizer will not push down aggregates. 
> i tried to fix this by adding some logic to the application but it makes the 
> code very clumsy with lot of branches. Instead i propose to revert  
> HIVE-18569  and let the user introduce an explicit cast this will be better 
> since the metada reflects actual storage type and push down aggregates will 
> kick in and there is no config needed without adding any code or bug.
> cc [~ashutoshc] and [~nishantbangarwa]
> You can see the difference with the following DDL
> {code:java}
> create table test_base_table(`timecolumn` timestamp, `interval_marker` 
> string, `num_l` DECIMAL(10,2));
> insert into test_base_table values ('2015-03-08 00:00:00', 'i1-start', 4.5);
> set hive.druid.approx.result=true;
> CREATE TABLE druid_test_table
> STORED BY 'org.apache.hadoop.hive.druid.DruidStorageHandler'
> TBLPROPERTIES ("druid.segment.granularity" = "DAY")
> AS
> select cast(`timecolumn` as timestamp with local time zone) as `__time`, 
> `interval_marker`, cast(`num_l` as double)
> FROM test_base_table;
> describe druid_test_table;
> explain select sum(num_l), min(num_l) FROM druid_test_table;
> CREATE TABLE druid_test_table_2
> STORED BY 'org.apache.hadoop.hive.druid.DruidStorageHandler'
> TBLPROPERTIES ("druid.segment.granularity" = "DAY")
> AS
> select cast(`timecolumn` as timestamp with local time zone) as `__time`, 
> `interval_marker`, `num_l`
> FROM test_base_table;
> describe druid_test_table_2;
> explain select sum(num_l), min(num_l) FROM druid_test_table_2;
> {code}
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HIVE-19513) ptest version in pom.xml should be 1.0

2018-05-13 Thread Vihang Karajgaonkar (JIRA)

 [ 
https://issues.apache.org/jira/browse/HIVE-19513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vihang Karajgaonkar updated HIVE-19513:
---
Attachment: HIVE-19513.01.patch

> ptest version in pom.xml should be 1.0
> --
>
> Key: HIVE-19513
> URL: https://issues.apache.org/jira/browse/HIVE-19513
> Project: Hive
>  Issue Type: Sub-task
>Reporter: Vihang Karajgaonkar
>Assignee: Vihang Karajgaonkar
>Priority: Minor
> Attachments: HIVE-19513.01.patch
>
>
> Jenkins job has the hardcoded API point as 
> {{http://:8080/hive-ptest-1.0}}. Currently the pom.xml has version as 3.0 
> which creates a hive-ptest-3.0.war file which is not correct. Changing back 
> the version to 1.0 helps updating the ptest code without changing the jenkins 
> job API endpoint.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HIVE-19513) ptest version in pom.xml should be 1.0

2018-05-13 Thread Vihang Karajgaonkar (JIRA)

[ 
https://issues.apache.org/jira/browse/HIVE-19513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16473384#comment-16473384
 ] 

Vihang Karajgaonkar commented on HIVE-19513:


[~stakiar] Can you review?

> ptest version in pom.xml should be 1.0
> --
>
> Key: HIVE-19513
> URL: https://issues.apache.org/jira/browse/HIVE-19513
> Project: Hive
>  Issue Type: Sub-task
>Reporter: Vihang Karajgaonkar
>Assignee: Vihang Karajgaonkar
>Priority: Minor
> Attachments: HIVE-19513.01.patch
>
>
> Jenkins job has the hardcoded API point as 
> {{http://:8080/hive-ptest-1.0}}. Currently the pom.xml has version as 3.0 
> which creates a hive-ptest-3.0.war file which is not correct. Changing back 
> the version to 1.0 helps updating the ptest code without changing the jenkins 
> job API endpoint.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (HIVE-19513) ptest version in pom.xml should be 1.0

2018-05-13 Thread Vihang Karajgaonkar (JIRA)

 [ 
https://issues.apache.org/jira/browse/HIVE-19513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vihang Karajgaonkar reassigned HIVE-19513:
--


> ptest version in pom.xml should be 1.0
> --
>
> Key: HIVE-19513
> URL: https://issues.apache.org/jira/browse/HIVE-19513
> Project: Hive
>  Issue Type: Sub-task
>Reporter: Vihang Karajgaonkar
>Assignee: Vihang Karajgaonkar
>Priority: Minor
>
> Jenkins job has the hardcoded API point as 
> {{http://:8080/hive-ptest-1.0}}. Currently the pom.xml has version as 3.0 
> which creates a hive-ptest-3.0.war file which is not correct. Changing back 
> the version to 1.0 helps updating the ptest code without changing the jenkins 
> job API endpoint.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HIVE-19512) If parallel execution is enabled, metastore is throwing out of sequence error.

2018-05-13 Thread mahesh kumar behera (JIRA)

 [ 
https://issues.apache.org/jira/browse/HIVE-19512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

mahesh kumar behera updated HIVE-19512:
---
Labels:   (was: pull-request-available)

> If parallel execution is enabled, metastore is throwing out of sequence error.
> --
>
> Key: HIVE-19512
> URL: https://issues.apache.org/jira/browse/HIVE-19512
> Project: Hive
>  Issue Type: Task
>  Components: Hive, HiveServer2, repl
>Affects Versions: 3.1.0
>Reporter: mahesh kumar behera
>Assignee: mahesh kumar behera
>Priority: Major
> Fix For: 3.1.0
>
>
> The move task does meta store operations. If the meta hive object is shared 
> between Move tasks, then meta store throwing out of sequence error. So each 
> move task should have a hive object of its own. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HIVE-19512) If parallel execution is enabled, metastore is throwing out of sequence error.

2018-05-13 Thread mahesh kumar behera (JIRA)

 [ 
https://issues.apache.org/jira/browse/HIVE-19512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

mahesh kumar behera updated HIVE-19512:
---
Summary: If parallel execution is enabled, metastore is throwing out of 
sequence error.  (was: create thread local hive object for Movetask)

> If parallel execution is enabled, metastore is throwing out of sequence error.
> --
>
> Key: HIVE-19512
> URL: https://issues.apache.org/jira/browse/HIVE-19512
> Project: Hive
>  Issue Type: Task
>  Components: Hive, HiveServer2, repl
>Affects Versions: 3.1.0
>Reporter: mahesh kumar behera
>Assignee: mahesh kumar behera
>Priority: Major
>  Labels: pull-request-available
> Fix For: 3.1.0
>
>
> The move task does meta store operations. If the meta hive object is shared 
> between Move tasks, then meta store throwing out of sequence error. So each 
> move task should have a hive object of its own. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HIVE-19512) create thread local hive object for Movetask

2018-05-13 Thread mahesh kumar behera (JIRA)

 [ 
https://issues.apache.org/jira/browse/HIVE-19512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

mahesh kumar behera updated HIVE-19512:
---
Description: The move task does meta store operations. If the meta hive 
object is shared between Move tasks, then meta store throwing out of sequence 
error. So each move task should have a hive object of its own.   (was: * add a 
parameter at db level to identify if its a source of replication. beacon will 
set this.

 * Enable CM root only for databases that are a source of a replication policy, 
for other db's skip the CM root functionality.

 * prevent database drop if the parameter indicating its source of a 
replication, is set.

 * as an upgrade to this version, beacon should set the property on all 
existing database policies, in affect.

 * the parameter should be of the form . –  repl.source.for : List < policy ids 
>)

> create thread local hive object for Movetask
> 
>
> Key: HIVE-19512
> URL: https://issues.apache.org/jira/browse/HIVE-19512
> Project: Hive
>  Issue Type: Task
>  Components: Hive, HiveServer2, repl
>Affects Versions: 3.1.0
>Reporter: mahesh kumar behera
>Assignee: mahesh kumar behera
>Priority: Major
>  Labels: pull-request-available
> Fix For: 3.1.0
>
>
> The move task does meta store operations. If the meta hive object is shared 
> between Move tasks, then meta store throwing out of sequence error. So each 
> move task should have a hive object of its own. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (HIVE-19512) create thread local hive object for Movetask

2018-05-13 Thread mahesh kumar behera (JIRA)

 [ 
https://issues.apache.org/jira/browse/HIVE-19512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

mahesh kumar behera reassigned HIVE-19512:
--


> create thread local hive object for Movetask
> 
>
> Key: HIVE-19512
> URL: https://issues.apache.org/jira/browse/HIVE-19512
> Project: Hive
>  Issue Type: Task
>  Components: Hive, HiveServer2, repl
>Affects Versions: 3.1.0
>Reporter: mahesh kumar behera
>Assignee: mahesh kumar behera
>Priority: Major
>  Labels: pull-request-available
> Fix For: 3.1.0
>
>
> * add a parameter at db level to identify if its a source of replication. 
> beacon will set this.
>  * Enable CM root only for databases that are a source of a replication 
> policy, for other db's skip the CM root functionality.
>  * prevent database drop if the parameter indicating its source of a 
> replication, is set.
>  * as an upgrade to this version, beacon should set the property on all 
> existing database policies, in affect.
>  * the parameter should be of the form . –  repl.source.for : List < policy 
> ids >



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


<    1   2