[jira] [Created] (DRILL-6794) Document the JDBC properties required to retrieve result sets in batches while querying large tables
Rahul Raj created DRILL-6794: Summary: Document the JDBC properties required to retrieve result sets in batches while querying large tables Key: DRILL-6794 URL: https://issues.apache.org/jira/browse/DRILL-6794 Project: Apache Drill Issue Type: Bug Components: Documentation Affects Versions: 1.14.0 Reporter: Rahul Raj Document the JDBC properties required to retrieve result sets in batches while querying large tables Querying large tables using JDBC plugin causes OOM as most JDBC drivers cache the entire result set at the client by default. To avoid this additional parameters needs to be specified with the JDBC connection string so that the driver fetches records in batches and reloads when exhausted. For postgres driver set autocommit mode to false - jdbc:postgresql://url:port/schema?defaultAutoCommit=false Links [1] https://issues.apache.org/jira/browse/DRILL-4177 [2] https://jdbc.postgresql.org/documentation/93/query.html#fetchsize-example [3] https://www.postgresql.org/docs/9.3/static/ecpg-sql-set-autocommit.html [4] https://jdbc.postgresql.org/documentation/head/ds-cpds.htm -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DRILL-5578) Drill fails on date functions in 'where clause' when queried on a JDBC Storage plugin
[ https://issues.apache.org/jira/browse/DRILL-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371147#comment-16371147 ] Rahul Raj commented on DRILL-5578: -- Created https://issues.apache.org/jira/browse/CALCITE-2188 > Drill fails on date functions in 'where clause' when queried on a JDBC > Storage plugin > - > > Key: DRILL-5578 > URL: https://issues.apache.org/jira/browse/DRILL-5578 > Project: Apache Drill > Issue Type: Bug >Affects Versions: 1.9.0, 1.10.0 >Reporter: Rahul Raj >Priority: Major > > Drill 1.9/1.10 fails on any date manipulation in the where part while > querying on a table from JDBC Storage plugin. Issue happens on postgres and > Oracle. > The following two queries error out: > select * from config_1.APP.EXECUTIONSTEP where DATE_ADD(CAST(STARTED_AT as > DATE),interval '1' second) < CAST(CURRENT_DATE as DATE) > select `id` from (select * from config_1.public.project_release) where > CAST(DATE_ADD(`start_date`,interval '19800' second(5)) AS DATE) = DATE > '2011-11-11' > However date manipulation succeeds when date function are applied on the > selected fields > > select DATE_ADD(CAST(STARTED_AT as DATE),interval '1' second) < > CAST(CURRENT_DATE as DATE) from config_1.APP.EXECUTIONSTEP > select `id` from (select * from config_1.public.project_release) where > CAST(`start_date` AS DATE) = DATE '2011-11-11' > Error: > [Error Id: 048fe4b9-ecab-40fe-aca9-d57eb2df9b0c on vpc12.o3c.in:31010] > org.apache.drill.common.exceptions.UserException: SYSTEM ERROR: > AssertionError: 1000: INTERVAL_DAY_TIME > [Error Id: 048fe4b9-ecab-40fe-aca9-d57eb2df9b0c on vpc12.o3c.in:31010] > at > org.apache.drill.common.exceptions.UserException$Builder.build(UserException.java:543) > ~[drill-common-1.9.0.jar:1.9.0] > at > org.apache.drill.exec.work.foreman.Foreman$ForemanResult.close(Foreman.java:825) > [drill-java-exec-1.9.0.jar:1.9.0] > at > org.apache.drill.exec.work.foreman.Foreman.moveToState(Foreman.java:935) > [drill-java-exec-1.9.0.jar:1.9.0] > at org.apache.drill.exec.work.foreman.Foreman.run(Foreman.java:281) > [drill-java-exec-1.9.0.jar:1.9.0] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [na:1.8.0_60] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [na:1.8.0_60] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60] > Caused by: org.apache.drill.exec.work.foreman.ForemanException: Unexpected > exception during fragment initialization: 1000: INTERVAL_DAY_TIME > ... 4 common frames omitted > Caused by: java.lang.AssertionError: 1000: INTERVAL_DAY_TIME > at > org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:179) > ~[calcite-core-1.4.0-drill-r19.jar:1.4.0-drill-r19] > at > org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:268) > ~[calcite-core-1.4.0-drill-r19.jar:1.4.0-drill-r19] > at > org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:212) > ~[calcite-core-1.4.0-drill-r19.jar:1.4.0-drill-r19] > at > org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:268) > ~[calcite-core-1.4.0-drill-r19.jar:1.4.0-drill-r19] > at > org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:212) > ~[calcite-core-1.4.0-drill-r19.jar:1.4.0-drill-r19] > at > org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:268) > ~[calcite-core-1.4.0-drill-r19.jar:1.4.0-drill-r19] > at > org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:212) > ~[calcite-core-1.4.0-drill-r19.jar:1.4.0-drill-r19] > at > org.apache.calcite.adapter.jdbc.JdbcRules$JdbcFilter.implement(JdbcRules.java:658) > ~[calcite-core-1.4.0-drill-r19.jar:1.4.0-drill-r19] > at > org.apache.calcite.adapter.jdbc.JdbcImplementor.visitChild(JdbcImplementor.java:118) > ~[calcite-core-1.4.0-drill-r19.jar:1.4.0-drill-r19] > at org.apache.drill.exec.store.jdbc.JdbcPrel.(JdbcPrel.java:62) > ~[drill-jdbc-storage-1.9.0.jar:1.9.0] > at > org.apache.drill.exec.store.jdbc.JdbcIntermediatePrel.finalizeRel(JdbcIntermediatePrel.java:66) > ~[drill-jdbc-storage-1.9.0.jar:1.9.0] > at > org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler$PrelFinalizer.visit(DefaultSqlHandler.java:306) > ~[drill-java-exec-1.9.0.jar:1.9.0] > at > org.apache.calcite.rel.AbstractRelNode.accept(AbstractRelNode.java:256) > ~[calcite-core-1.4.0-drill-r19.jar:1.4.0-drill-r19] > at > org.apache.calcite.rel.RelShuttleImpl.visitChild(RelShuttleImpl.java:53) >
[jira] [Commented] (DRILL-5578) Drill fails on date functions in 'where clause' when queried on a JDBC Storage plugin
[ https://issues.apache.org/jira/browse/DRILL-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16366900#comment-16366900 ] Rahul Raj commented on DRILL-5578: -- I tried on drill-java-exec-1.13.0-SNAPSHOT which has the latest calcite changes and the stack trace is below: org.apache.drill.common.exceptions.UserException: SYSTEM ERROR: UnsupportedOperationException: class org.apache.calcite.sql.SqlSyntax$6: SPECIAL [Error Id: d3399f0a-fac2-44d1-832a-e3c762825767 on rahul-Latitude-E5440:31010] at org.apache.drill.common.exceptions.UserException$Builder.build(UserException.java:633) ~[drill-common-1.13.0-SNAPSHOT.jar:1.13.0-SNAPSHOT] at org.apache.drill.exec.work.foreman.Foreman$ForemanResult.close(Foreman.java:761) [drill-java-exec-1.13.0-SNAPSHOT.jar:1.13.0-SNAPSHOT] at org.apache.drill.exec.work.foreman.QueryStateProcessor.checkCommonStates(QueryStateProcessor.java:327) [drill-java-exec-1.13.0-SNAPSHOT.jar:1.13.0-SNAPSHOT] at org.apache.drill.exec.work.foreman.QueryStateProcessor.planning(QueryStateProcessor.java:223) [drill-java-exec-1.13.0-SNAPSHOT.jar:1.13.0-SNAPSHOT] at org.apache.drill.exec.work.foreman.QueryStateProcessor.moveToState(QueryStateProcessor.java:83) [drill-java-exec-1.13.0-SNAPSHOT.jar:1.13.0-SNAPSHOT] at org.apache.drill.exec.work.foreman.Foreman.run(Foreman.java:281) [drill-java-exec-1.13.0-SNAPSHOT.jar:1.13.0-SNAPSHOT] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_151] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_151] at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151] Caused by: org.apache.drill.exec.work.foreman.ForemanException: Unexpected exception during fragment initialization: class org.apache.calcite.sql.SqlSyntax$6: SPECIAL at org.apache.drill.exec.work.foreman.Foreman.run(Foreman.java:282) [drill-java-exec-1.13.0-SNAPSHOT.jar:1.13.0-SNAPSHOT] ... 3 common frames omitted Caused by: java.lang.UnsupportedOperationException: class org.apache.calcite.sql.SqlSyntax$6: SPECIAL at org.apache.calcite.util.Util.needToImplement(Util.java:925) ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0] at org.apache.calcite.sql.SqlSyntax$6.unparse(SqlSyntax.java:116) ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0] at org.apache.calcite.sql.SqlOperator.unparse(SqlOperator.java:332) ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0] at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:332) ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0] at org.apache.calcite.sql.dialect.MysqlSqlDialect.unparseCall(MysqlSqlDialect.java:154) ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0] at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:103) ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0] at org.apache.calcite.sql.SqlUtil.unparseBinarySyntax(SqlUtil.java:323) ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0] at org.apache.calcite.sql.SqlSyntax$3.unparse(SqlSyntax.java:65) ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0] at org.apache.calcite.sql.SqlOperator.unparse(SqlOperator.java:332) ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0] at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:332) ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0] at org.apache.calcite.sql.dialect.MysqlSqlDialect.unparseCall(MysqlSqlDialect.java:154) ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0] at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:103) ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0] at org.apache.calcite.sql.SqlNodeList.andOrList(SqlNodeList.java:142) ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0] at org.apache.calcite.sql.SqlOperator.unparseListClause(SqlOperator.java:347) ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0] at org.apache.calcite.sql.SqlSelectOperator.unparse(SqlSelectOperator.java:197) ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0] at org.apache.calcite.sql.SqlSelect.unparse(SqlSelect.java:240) ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0] at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:152) ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0] at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:158) ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0] at org.apache.drill.exec.store.jdbc.JdbcPrel.(JdbcPrel.java:65) ~[drill-jdbc-storage-1.13.0-SNAPSHOT.jar:1.13.0-SNAPSHOT] at org.apache.drill.exec.store.jdbc.JdbcIntermediatePrel.finalizeRel(JdbcIntermediatePrel.java:66) ~[drill-jdbc-storage-1.13.0-SNAPSHOT.jar:1.13.0-SNAPSHOT] at org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler$PrelFinalizer.visit(DefaultSqlHandler.java:309) ~[drill-java-exec-1.13.0-SNAPSHOT.jar:1.13.0-SNAPSHOT] at org.apache.calcite.rel.AbstractRelNode.accept(AbstractRelNode.java:279) ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0] at
[jira] [Created] (DRILL-6016) Error reading INT96 created by Apache Spark
Rahul Raj created DRILL-6016: Summary: Error reading INT96 created by Apache Spark Key: DRILL-6016 URL: https://issues.apache.org/jira/browse/DRILL-6016 Project: Apache Drill Issue Type: Bug Environment: Drill 1.11 Reporter: Rahul Raj Hi, I am getting the error - SYSTEM ERROR : ClassCastException: org.apache.drill.exec.vector.TimeStampVector cannot be cast to org.apache.drill.exec.vector.VariableWidthVector while trying to read a spark INT96 datetime field on Drill 1.11 in spite of setting the property store.parquet.reader.int96_as_timestamp to true. I believe this was fixed in drill 1.10(https://issues.apache.org/jira/browse/DRILL-4373). What could be wrong. I have attached the dataset at https://github.com/rajrahul/files/blob/master/result.tar.gz -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DRILL-2362) Drill should manage Query Profiling archiving
[ https://issues.apache.org/jira/browse/DRILL-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16146664#comment-16146664 ] Rahul Raj commented on DRILL-2362: -- We had more than 200,000 profiles stored in the default location and it made the profile page access extremely slow. Also while accessing this page, client connections were disconnected (channel closed exception) - could be related to a large GC causing missed heart beats. -Rahul > Drill should manage Query Profiling archiving > - > > Key: DRILL-2362 > URL: https://issues.apache.org/jira/browse/DRILL-2362 > Project: Apache Drill > Issue Type: Bug > Components: Storage - Other >Affects Versions: 0.7.0 >Reporter: Chris Westin > Fix For: Future > > > We collect query profile information for analysis purposes, but we keep it > forever. At this time, for a few queries, it isn't a problem. But as users > start putting Drill into production, automated use via other applications > will make this grow quickly. We need to come up with a retention policy > mechanism, with suitable settings administrators can use, and implement it so > that this data can be cleaned up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (DRILL-5578) Drill fails on date functions in 'where clause' when queried on a JDBC Storage plugin
Rahul Raj created DRILL-5578: Summary: Drill fails on date functions in 'where clause' when queried on a JDBC Storage plugin Key: DRILL-5578 URL: https://issues.apache.org/jira/browse/DRILL-5578 Project: Apache Drill Issue Type: Bug Affects Versions: 1.10.0, 1.9.0 Reporter: Rahul Raj Drill 1.9/1.10 fails on any date manipulation in the where part while querying on a table from JDBC Storage plugin. Issue happens on postgres and Oracle. The following two queries error out: select * from config_1.APP.EXECUTIONSTEP where DATE_ADD(CAST(STARTED_AT as DATE),interval '1' second) < CAST(CURRENT_DATE as DATE) select `id` from (select * from config_1.public.project_release) where CAST(DATE_ADD(`start_date`,interval '19800' second(5)) AS DATE) = DATE '2011-11-11' However date manipulation succeeds when date function are applied on the selected fields select DATE_ADD(CAST(STARTED_AT as DATE),interval '1' second) < CAST(CURRENT_DATE as DATE) from config_1.APP.EXECUTIONSTEP select `id` from (select * from config_1.public.project_release) where CAST(`start_date` AS DATE) = DATE '2011-11-11' Error: [Error Id: 048fe4b9-ecab-40fe-aca9-d57eb2df9b0c on vpc12.o3c.in:31010] org.apache.drill.common.exceptions.UserException: SYSTEM ERROR: AssertionError: 1000: INTERVAL_DAY_TIME [Error Id: 048fe4b9-ecab-40fe-aca9-d57eb2df9b0c on vpc12.o3c.in:31010] at org.apache.drill.common.exceptions.UserException$Builder.build(UserException.java:543) ~[drill-common-1.9.0.jar:1.9.0] at org.apache.drill.exec.work.foreman.Foreman$ForemanResult.close(Foreman.java:825) [drill-java-exec-1.9.0.jar:1.9.0] at org.apache.drill.exec.work.foreman.Foreman.moveToState(Foreman.java:935) [drill-java-exec-1.9.0.jar:1.9.0] at org.apache.drill.exec.work.foreman.Foreman.run(Foreman.java:281) [drill-java-exec-1.9.0.jar:1.9.0] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_60] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_60] at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60] Caused by: org.apache.drill.exec.work.foreman.ForemanException: Unexpected exception during fragment initialization: 1000: INTERVAL_DAY_TIME ... 4 common frames omitted Caused by: java.lang.AssertionError: 1000: INTERVAL_DAY_TIME at org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:179) ~[calcite-core-1.4.0-drill-r19.jar:1.4.0-drill-r19] at org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:268) ~[calcite-core-1.4.0-drill-r19.jar:1.4.0-drill-r19] at org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:212) ~[calcite-core-1.4.0-drill-r19.jar:1.4.0-drill-r19] at org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:268) ~[calcite-core-1.4.0-drill-r19.jar:1.4.0-drill-r19] at org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:212) ~[calcite-core-1.4.0-drill-r19.jar:1.4.0-drill-r19] at org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:268) ~[calcite-core-1.4.0-drill-r19.jar:1.4.0-drill-r19] at org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:212) ~[calcite-core-1.4.0-drill-r19.jar:1.4.0-drill-r19] at org.apache.calcite.adapter.jdbc.JdbcRules$JdbcFilter.implement(JdbcRules.java:658) ~[calcite-core-1.4.0-drill-r19.jar:1.4.0-drill-r19] at org.apache.calcite.adapter.jdbc.JdbcImplementor.visitChild(JdbcImplementor.java:118) ~[calcite-core-1.4.0-drill-r19.jar:1.4.0-drill-r19] at org.apache.drill.exec.store.jdbc.JdbcPrel.(JdbcPrel.java:62) ~[drill-jdbc-storage-1.9.0.jar:1.9.0] at org.apache.drill.exec.store.jdbc.JdbcIntermediatePrel.finalizeRel(JdbcIntermediatePrel.java:66) ~[drill-jdbc-storage-1.9.0.jar:1.9.0] at org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler$PrelFinalizer.visit(DefaultSqlHandler.java:306) ~[drill-java-exec-1.9.0.jar:1.9.0] at org.apache.calcite.rel.AbstractRelNode.accept(AbstractRelNode.java:256) ~[calcite-core-1.4.0-drill-r19.jar:1.4.0-drill-r19] at org.apache.calcite.rel.RelShuttleImpl.visitChild(RelShuttleImpl.java:53) ~[calcite-core-1.4.0-drill-r19.jar:1.4.0-drill-r19] at org.apache.calcite.rel.RelShuttleImpl.visitChildren(RelShuttleImpl.java:68) ~[calcite-core-1.4.0-drill-r19.jar:1.4.0-drill-r19] at org.apache.calcite.rel.RelShuttleImpl.visit(RelShuttleImpl.java:126) ~[calcite-core-1.4.0-drill-r19.jar:1.4.0-drill-r19] at org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler$PrelFinalizer.visit(DefaultSqlHandler.java:308) ~[drill-java-exec-1.9.0.jar:1.9.0] at
[jira] [Created] (DRILL-5577) Column alias are ignored when Storage Plugin is enabled
Rahul Raj created DRILL-5577: Summary: Column alias are ignored when Storage Plugin is enabled Key: DRILL-5577 URL: https://issues.apache.org/jira/browse/DRILL-5577 Project: Apache Drill Issue Type: Bug Affects Versions: 1.10.0 Reporter: Rahul Raj Drill ignores column aliases when a JDBC storage plugin is enabled. If I execute 'select destination as x from ...some.csv' the column name appears as 'destination' instead of 'x' while JDBC storage plugin is enabled. On disabling the storage plugin, drill returns the results with aliased name 'x'. This could be related to https://issues.apache.org/jira/browse/DRILL-4903, where results return the implicit columns(fqn,filepath etc..) as well. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (DRILL-5343) Wrong results on repeated DATE_ADD
Rahul Raj created DRILL-5343: Summary: Wrong results on repeated DATE_ADD Key: DRILL-5343 URL: https://issues.apache.org/jira/browse/DRILL-5343 Project: Apache Drill Issue Type: Bug Affects Versions: 1.9.0 Reporter: Rahul Raj On Drill 1.9, DATE_ADD(DATE_ADD ...) results in the inner most value getting added up N times. Its seen on MINUTE/SECOND/HOUR interval values, It works fine on DAY interval See the results below; I have trimmed the sqlline results for brevity. SELECT DATE_ADD(TIME '12:23:34',INTERVAL '1' minute) from (values(1)); +---+ | 12:24:34 | +---+ SELECT DATE_ADD(TIME '12:23:34',INTERVAL '5' minute) from (values(1)); +---+ | 12:28:34 | +---+ SELECT DATE_ADD(DATE_ADD(TIME '12:23:34',INTERVAL '5' minute),INTERVAL '1' minute) from (values(1)); +---+ | 12:33:34 | +---+ SELECT DATE_ADD(DATE_ADD(DATE_ADD(TIME '12:23:34',INTERVAL '5' minute),INTERVAL '1' minute),INTERVAL '2' minute) from (values(1)); +---+ | 12:38:34 | +---+ SELECT DATE_ADD(DATE_ADD(DATE '2008-2-23',INTERVAL '5' minute),INTERVAL '2' minute) from (values(1)); ++ | 2008-02-23 00:10:00.0 | ++ SELECT DATE_ADD(DATE_ADD(DATE '2008-2-23',INTERVAL '5' second),INTERVAL '2' second) from (values(1)); ++ | 2008-02-23 00:00:10.0 | ++ SELECT DATE_ADD(DATE_ADD(DATE '2008-2-23',INTERVAL '5' hour),INTERVAL '2' hour) from (values(1)); ++ | 2008-02-23 10:00:00.0 | ++ DAY interval works fine. SELECT DATE_ADD(DATE '2008-2-23',INTERVAL '5' day) from (values(1)); ++ | 2008-02-28 00:00:00.0 | ++ SELECT DATE_ADD(DATE_ADD(DATE '2008-2-23',INTERVAL '5' day),INTERVAL '1' day) from (values(1)); ++ | 2008-02-29 00:00:00.0 | ++ SELECT DATE_ADD(DATE_ADD(DATE '2008-2-23',INTERVAL '5' day),INTERVAL '2' day) from (values(1)); ++ | 2008-03-01 00:00:00.0 | ++ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] (DRILL-5229) Upgrade kudu client to org.apache.kudu:kudu-client:1.2.0
Title: Message Title Rahul Raj commented on DRILL-5229 Re: Upgrade kudu client to org.apache.kudu:kudu-client:1.2.0 The library change has fixed the out of order key issue. Will test some more and make a pull request Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
[jira] [Created] (DRILL-5229) Upgrade kudu client to org.apache.kudu:kudu-client:1.2.0
Rahul Raj created DRILL-5229: Summary: Upgrade kudu client to org.apache.kudu:kudu-client:1.2.0 Key: DRILL-5229 URL: https://issues.apache.org/jira/browse/DRILL-5229 Project: Apache Drill Issue Type: Bug Components: Storage - Other Affects Versions: 1.8.0 Reporter: Rahul Raj Fix For: 2.0.0 Getting an error -" out-of-order key" for a query select v,count(k) from kudu.test group by v where k is the primary key. This happens only when the aggregation is done on primary key. Should drill move to the latest kudu client to investigate this further? Current drill kudu connector uses org.kududb:kudu-client:0.6.0 from cloudera repository, where the latest released library org.apache.kudu:kudu-client:1.2.0 is hosted on maven central. There are a few breaking changes with the new library: 1. TIMESTAMP renamed to UNIXTIME_MICROS 2. In KuduRecordReader#setup - KuduScannerBuilder#lowerBoundPartitionKeyRaw renamed to lowerBoundRaw andKuduScannerBuilder#exclusiveUpperBoundPartitionKeyRaw renamed exclusiveUpperBoundRaw. Both methods are deprecated. 3. In KuduRecordWriterImpl#updateSchema - client.createTable(name, kuduSchema) requires CreateTableOperatios as the third argument -- This message was sent by Atlassian JIRA (v6.3.4#6332)
