[GitHub] [drill] akkapur commented on a change in pull request #1888: DRILL-5956: Add Storage Plugin for Apache Druid

[GitBox]

akkapur commented on a change in pull request #1888:
URL: https://github.com/apache/drill/pull/1888#discussion_r419190071



##
File path: 
contrib/storage-druid/src/main/java/org/apache/drill/exec/store/druid/common/DruidBoundFilter.java
##
@@ -0,0 +1,123 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.drill.exec.store.druid.common;
+
+import com.fasterxml.jackson.annotation.JsonCreator;
+import com.fasterxml.jackson.annotation.JsonProperty;
+import com.fasterxml.jackson.core.JsonProcessingException;
+import com.fasterxml.jackson.databind.ObjectMapper;
+import org.apache.commons.lang3.StringUtils;
+
+import java.util.HashMap;
+
+public class DruidBoundFilter {
+
+  private static final ObjectMapper objectMapper = new ObjectMapper();
+  private String type = DruidCompareOp.TYPE_BOUND.getCompareOp();
+  private String dimension;
+  private String lower;
+  private String upper;
+  private Boolean lowerStrict =  false;
+  private Boolean upperStrict = false;
+
+  @JsonCreator
+  public DruidBoundFilter(@JsonProperty("dimension") String dimension,
+  @JsonProperty("lower") String lower,
+  @JsonProperty("upper") String upper) {
+this.dimension = dimension;
+this.lower = lower;
+this.upper= upper;
+  }
+
+  @JsonCreator
+  public DruidBoundFilter(@JsonProperty("dimension") String dimension,
+  @JsonProperty("lower") String lower,
+  @JsonProperty("upper") String upper,
+  @JsonProperty("lowerStrict") Boolean lowerStrict,
+  @JsonProperty("upperStrict") Boolean upperStrict) {
+this.dimension = dimension;
+this.lower = lower;
+this.upper= upper;
+this.lowerStrict = lowerStrict;
+this.upperStrict = upperStrict;
+  }
+
+  public String getType() {
+return type;
+  }
+
+  public void setType(String type) {
+this.type = type;
+  }
+
+  public String getDimension() {
+return dimension;
+  }
+
+  public void setDimension(String dimension) {
+this.dimension = dimension;
+  }
+
+  public String getLower() {
+return lower;
+  }
+
+  public void setLower(String lower) {
+this.lower = lower;
+  }
+
+  public String getUpper() {
+return upper;
+  }
+
+  public void setUpper(String upper) {
+this.upper = upper;
+  }
+
+  public Boolean getLowerStrict() {
+return lowerStrict;
+  }
+
+  public void setLowerStrict(Boolean lowerStrict) {
+this.lowerStrict = lowerStrict;
+  }
+
+  public Boolean getUpperStrict() {
+return upperStrict;
+  }
+
+  public void setUpperStrict(Boolean upperStrict) {
+this.upperStrict = upperStrict;
+  }
+
+  public String toJson() throws JsonProcessingException {

Review comment:
   Fixed, I think i was eating bourbon burgers at times.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: compile issue with MapR repo is being worked

[Charles Givre]

Hi Ted, 
Thanks for your help.  You can view the logs here: 
https://github.com/apache/drill/pull/2067 
 in the CI stuff.
-- C




> On May 3, 2020, at 9:16 PM, Ted Dunning  wrote:
> 
> I will pass the word.
> 
> Do you have logs?
> 
> 
> On Sun, May 3, 2020 at 4:15 PM Charles Givre  wrote:
> 
>> Hi Ted,
>> Thanks for looking into this so quickly.  Unfortunately, I re-ran the CI
>> jobs from github and it is still producing the same errors.
>> Best,
>> --C
>> 
>>> On May 3, 2020, at 5:58 PM, Ted Dunning  wrote:
>>> 
>>> It appears that the certificate issue is resolved.
>>> 
>>> Can somebody verify this by doing a compilation?
>>> 
>>> I have to add that based on the number of off-line and on-list pings I
>> got
>>> about this issue I can say that there were quite a few people compiling
>>> Drill on a Sunday morning. That bodes well, I think, for community
>> health.
>>> 
>>> 
>>> 
>>> On Sun, May 3, 2020 at 11:27 AM Ted Dunning 
>> wrote:
>>> 
 
 I just got word back that the team is looking at the issue.
 
 Not surprisingly, their first look indicates that the issue isn't what
>> it
 appears to be (i.e. not a bad cert)
 
 
 
>> 
>> 

Re: compile issue with MapR repo is being worked

[Ted Dunning]

I will pass the word.

Do you have logs?


On Sun, May 3, 2020 at 4:15 PM Charles Givre  wrote:

> Hi Ted,
> Thanks for looking into this so quickly.  Unfortunately, I re-ran the CI
> jobs from github and it is still producing the same errors.
> Best,
> --C
>
> > On May 3, 2020, at 5:58 PM, Ted Dunning  wrote:
> >
> > It appears that the certificate issue is resolved.
> >
> > Can somebody verify this by doing a compilation?
> >
> > I have to add that based on the number of off-line and on-list pings I
> got
> > about this issue I can say that there were quite a few people compiling
> > Drill on a Sunday morning. That bodes well, I think, for community
> health.
> >
> >
> >
> > On Sun, May 3, 2020 at 11:27 AM Ted Dunning 
> wrote:
> >
> >>
> >> I just got word back that the team is looking at the issue.
> >>
> >> Not surprisingly, their first look indicates that the issue isn't what
> it
> >> appears to be (i.e. not a bad cert)
> >>
> >>
> >>
>
>

Re: compile issue with MapR repo is being worked

[Charles Givre]

Hi Ted, 
Thanks for looking into this so quickly.  Unfortunately, I re-ran the CI jobs 
from github and it is still producing the same errors. 
Best,
--C

> On May 3, 2020, at 5:58 PM, Ted Dunning  wrote:
> 
> It appears that the certificate issue is resolved.
> 
> Can somebody verify this by doing a compilation?
> 
> I have to add that based on the number of off-line and on-list pings I got
> about this issue I can say that there were quite a few people compiling
> Drill on a Sunday morning. That bodes well, I think, for community health.
> 
> 
> 
> On Sun, May 3, 2020 at 11:27 AM Ted Dunning  wrote:
> 
>> 
>> I just got word back that the team is looking at the issue.
>> 
>> Not surprisingly, their first look indicates that the issue isn't what it
>> appears to be (i.e. not a bad cert)
>> 
>> 
>> 

Re: Drill with No-SQL [was: Cannot Build Drill "exec/Java Execution Engine"]

[Paul Rogers]

Thanks for the update; I hadn't picked up on that bit of confusion about Presto.

I just did a Drill build, seemed to work, thanks for the fix. However, I don't 
know if I had the needed dependency cached, so my build might have worked 
anyway...

Thanks,
- Paul

 

On Sunday, May 3, 2020, 3:09:58 PM PDT, Ted Dunning  
wrote:  
 
 I didn't mention Presto on purpose. It is a fine tool, but the community is
plagued lately by a fork. That can be expected to substantially inhibit
adoption and I think that is just what I have seen. It used to be that
people asked about Presto every other time I was on a call and I haven't
heard even one such question in over a year. The community may recover from
this, but it is hard to say whether they can regain their momentum.

In case anybody wants to sample the confusion, here are the two "official"
homes on github:

https://github.com/prestodb/presto
https://github.com/prestosql/presto

The worst part is that neither fork seems to dominate the other. With the
Hudson/Jeeves fork, at least, Hudson basically dies while Jenkins continued
with full momentum. Here, both sides seem to be splitting things much too
evenly.



On Sun, May 3, 2020 at 2:42 PM Paul Rogers 
wrote:

> Hi Tug,
>
> Glad to hear from you again. Ted's summary is pretty good; here's a bit
> more detail.
>
>
> Presto is another alternative which seems to have gained the most traction
> outside of the Cloud ecosystem on the one hand, and the
> Cloudera/HortonWorks ecosystem on the other. Presto does, however, demand
> that you have a schema, which is often an obstacle for many applications.
>
> Most folks I've talked to who tried to use Spark for this use case came
> away disappointed. Unlike Drill (or Presto or Impala), Spark wants to start
> new Java processes for each query. Makes great sense for large, complex
> map/reduce jobs, but is a non-starter for small, interactive queries.
>
> Hive also is trying to be an "uber query layer" and has integrations with
> multiple systems. But, Hive's complexity makes Drill look downright simple
> by comparison. Hive also needs an up-front schema.
>
>
> I've had the opportunity to integrate Drill with two different noSQL
> engines. Getting started is easy, especially if a REST or similar API is
> available. Filter push-down is the next step as otherwise Drill will simply
> suck all data from your DB as it it were a file. We've added some structure
> in the new HTTP reader to make it a bit easier than it used to be to create
> this kind of filter push-down. (The other kind of filter push-down is for
> partition pruning used for files, which you probably won't need.)
>
> Aside from the current MapR repo issues, Drill tends to be much easier to
> build than other systems. Pretty much set up Java and the correct Maven and
> you're good to go. If you run unit tests, there is one additional library
> to install, but the tests themselves tell you you exactly what is needed
> when they fail the first time (which I how I learned about it.)
>
>
> After that, performance will point the way. For example, does your DB have
> indexes? If so, then you can leverage the work originally done for MapR-DB
> to convey index information to Calcite so it can pick the best execution
> plan. There are specialized operators for index key lookup as well.
>
> All this will get you the basic one-table scan which is often all that
> no-SQL DBs ever need. (Any structure usually appears within each document,
> rather than as joined table as in the RDBMS world.) However, if your DB
> does need joins, you will need something like Calcite to work out the
> tradeoffs of the various join+filter-push plans possible, especially if
> your DB supports multiple indexes. There is no escaping the plan-time
> complexity of these cases. Calcite is big and complex, but it does give you
> the tools needed to solve these problems.
>
> If your DB is to be used to power dashboards (summaries of logs, time
> series, click streams, sales or whatever), you'll soon find you need to
> provide a caching/aggregation layer to avoid banging on your DB each time
> the dashboard refreshes. (Imagine a 1-week dashboard, updated every minute,
> where only the last hour has new data.) Drill becomes very handy as a way
> of combining data from a mostly-static caching layer (data for the last 6
> days, say) with your live DB (for the last one day, say.)
>
> If you provide a "writer" as well as a "reader", you can use Drill to load
> your DB as well as query it.
>
>
> Happy to share whatever else I might have learned if you can describe your
> goals in a bit more detail.
>
> Thanks,
> - Paul
>
>
>
>    On Sunday, May 3, 2020, 11:25:11 AM PDT, Ted Dunning <
> ted.dunn...@gmail.com> wrote:
>
>  The compile problem is a problem with the MapR repo (I think). I have
> reported it to the folks who can fix it.
>
> Regarding the generic question, I think that Drill is very much a good
> choice for putting a SQL layer on a noSQL database.
>

[GitHub] [drill] paul-rogers commented on a change in pull request #2072: DRILL-7724: Refactor metadata controller batch

[GitBox]

paul-rogers commented on a change in pull request #2072:
URL: https://github.com/apache/drill/pull/2072#discussion_r419167392



##
File path: 
exec/java-exec/src/main/java/org/apache/drill/exec/physical/impl/metadata/MetadataControllerBatch.java
##
@@ -127,113 +126,93 @@ protected MetadataControllerBatch(MetadataControllerPOP 
popConfig,
 ? null
 : popConfig.getContext().metadataToHandle().stream()
 .collect(Collectors.toMap(MetadataInfo::identifier, 
Function.identity()));
-this.metadataUnits = new ArrayList<>();
-this.statisticsCollector = new StatisticsCollectorImpl();
 this.columnNamesOptions = new ColumnNamesOptions(context.getOptions());
   }
 
-  protected boolean setupNewSchema() {
-container.clear();
-container.addOrGet(MetastoreAnalyzeConstants.OK_FIELD_NAME, 
Types.required(TypeProtos.MinorType.BIT), null);
-container.addOrGet(MetastoreAnalyzeConstants.SUMMARY_FIELD_NAME, 
Types.required(TypeProtos.MinorType.VARCHAR), null);
-container.buildSchema(BatchSchema.SelectionVectorMode.NONE);
-container.setEmpty();
-return true;
-  }
-
   @Override
   public IterOutcome innerNext() {
-IterOutcome outcome;
-boolean finishedLeft;
-if (finished) {
-  return IterOutcome.NONE;
-}
+while (state != State.FINISHED) {
+  switch (state) {
+case RIGHT: {
 
-if (!finishedRight) {
-  outcome = handleRightIncoming();
-  if (outcome != null) {
-return outcome;
+  // Can only return NOT_YET
+  IterOutcome outcome = handleRightIncoming();
+  if (outcome != null) {
+return outcome;
+  }
+  break;
+}
+case LEFT: {
+
+  // Can only return NOT_YET
+  IterOutcome outcome = handleLeftIncoming();
+  if (outcome != null) {
+return outcome;
+  }
+  break;
+}
+case WRITE:
+  writeToMetastore();
+  createSummary();
+  state = State.FINISHED;
+  return IterOutcome.OK_NEW_SCHEMA;
+
+case FINISHED:
+  break;
+
+default:
+  throw new IllegalStateException(state.name());
   }
 }
+return IterOutcome.NONE;
+  }
 
+  private IterOutcome handleRightIncoming() {
 outer:
-while (true) {
-  outcome = next(0, left);
+for (;;) {

Review comment:
   Interesting. Which IDE warns? With which warning? Eclipse is fine with 
either syntax. I can perhaps add a warning in Eclipse to match your IDE. Looks 
like we use the `for (;;)` pattern in many places. I went ahead and fixed them. 
We should add the `while (true)` preference to our list of developer guidelines.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: Drill with No-SQL [was: Cannot Build Drill "exec/Java Execution Engine"]

[Ted Dunning]

I didn't mention Presto on purpose. It is a fine tool, but the community is
plagued lately by a fork. That can be expected to substantially inhibit
adoption and I think that is just what I have seen. It used to be that
people asked about Presto every other time I was on a call and I haven't
heard even one such question in over a year. The community may recover from
this, but it is hard to say whether they can regain their momentum.

In case anybody wants to sample the confusion, here are the two "official"
homes on github:

https://github.com/prestodb/presto
https://github.com/prestosql/presto

The worst part is that neither fork seems to dominate the other. With the
Hudson/Jeeves fork, at least, Hudson basically dies while Jenkins continued
with full momentum. Here, both sides seem to be splitting things much too
evenly.



On Sun, May 3, 2020 at 2:42 PM Paul Rogers 
wrote:

> Hi Tug,
>
> Glad to hear from you again. Ted's summary is pretty good; here's a bit
> more detail.
>
>
> Presto is another alternative which seems to have gained the most traction
> outside of the Cloud ecosystem on the one hand, and the
> Cloudera/HortonWorks ecosystem on the other. Presto does, however, demand
> that you have a schema, which is often an obstacle for many applications.
>
> Most folks I've talked to who tried to use Spark for this use case came
> away disappointed. Unlike Drill (or Presto or Impala), Spark wants to start
> new Java processes for each query. Makes great sense for large, complex
> map/reduce jobs, but is a non-starter for small, interactive queries.
>
> Hive also is trying to be an "uber query layer" and has integrations with
> multiple systems. But, Hive's complexity makes Drill look downright simple
> by comparison. Hive also needs an up-front schema.
>
>
> I've had the opportunity to integrate Drill with two different noSQL
> engines. Getting started is easy, especially if a REST or similar API is
> available. Filter push-down is the next step as otherwise Drill will simply
> suck all data from your DB as it it were a file. We've added some structure
> in the new HTTP reader to make it a bit easier than it used to be to create
> this kind of filter push-down. (The other kind of filter push-down is for
> partition pruning used for files, which you probably won't need.)
>
> Aside from the current MapR repo issues, Drill tends to be much easier to
> build than other systems. Pretty much set up Java and the correct Maven and
> you're good to go. If you run unit tests, there is one additional library
> to install, but the tests themselves tell you you exactly what is needed
> when they fail the first time (which I how I learned about it.)
>
>
> After that, performance will point the way. For example, does your DB have
> indexes? If so, then you can leverage the work originally done for MapR-DB
> to convey index information to Calcite so it can pick the best execution
> plan. There are specialized operators for index key lookup as well.
>
> All this will get you the basic one-table scan which is often all that
> no-SQL DBs ever need. (Any structure usually appears within each document,
> rather than as joined table as in the RDBMS world.) However, if your DB
> does need joins, you will need something like Calcite to work out the
> tradeoffs of the various join+filter-push plans possible, especially if
> your DB supports multiple indexes. There is no escaping the plan-time
> complexity of these cases. Calcite is big and complex, but it does give you
> the tools needed to solve these problems.
>
> If your DB is to be used to power dashboards (summaries of logs, time
> series, click streams, sales or whatever), you'll soon find you need to
> provide a caching/aggregation layer to avoid banging on your DB each time
> the dashboard refreshes. (Imagine a 1-week dashboard, updated every minute,
> where only the last hour has new data.) Drill becomes very handy as a way
> of combining data from a mostly-static caching layer (data for the last 6
> days, say) with your live DB (for the last one day, say.)
>
> If you provide a "writer" as well as a "reader", you can use Drill to load
> your DB as well as query it.
>
>
> Happy to share whatever else I might have learned if you can describe your
> goals in a bit more detail.
>
> Thanks,
> - Paul
>
>
>
> On Sunday, May 3, 2020, 11:25:11 AM PDT, Ted Dunning <
> ted.dunn...@gmail.com> wrote:
>
>  The compile problem is a problem with the MapR repo (I think). I have
> reported it to the folks who can fix it.
>
> Regarding the generic question, I think that Drill is very much a good
> choice for putting a SQL layer on a noSQL database.
>
> It is definitely the case that the community is much broader than it used
> to be. A number of companies now use Drill in their products which is
> one of the best ways to build long-term community.
>
> There are alternatives, of course. All have trade-offs (because we live in
> the world):
>
> - Calcite itself (what Drill uses as 

[GitHub] [drill] paul-rogers commented on a change in pull request #2072: DRILL-7724: Refactor metadata controller batch

[GitBox]

paul-rogers commented on a change in pull request #2072:
URL: https://github.com/apache/drill/pull/2072#discussion_r419167392



##
File path: 
exec/java-exec/src/main/java/org/apache/drill/exec/physical/impl/metadata/MetadataControllerBatch.java
##
@@ -127,113 +126,93 @@ protected MetadataControllerBatch(MetadataControllerPOP 
popConfig,
 ? null
 : popConfig.getContext().metadataToHandle().stream()
 .collect(Collectors.toMap(MetadataInfo::identifier, 
Function.identity()));
-this.metadataUnits = new ArrayList<>();
-this.statisticsCollector = new StatisticsCollectorImpl();
 this.columnNamesOptions = new ColumnNamesOptions(context.getOptions());
   }
 
-  protected boolean setupNewSchema() {
-container.clear();
-container.addOrGet(MetastoreAnalyzeConstants.OK_FIELD_NAME, 
Types.required(TypeProtos.MinorType.BIT), null);
-container.addOrGet(MetastoreAnalyzeConstants.SUMMARY_FIELD_NAME, 
Types.required(TypeProtos.MinorType.VARCHAR), null);
-container.buildSchema(BatchSchema.SelectionVectorMode.NONE);
-container.setEmpty();
-return true;
-  }
-
   @Override
   public IterOutcome innerNext() {
-IterOutcome outcome;
-boolean finishedLeft;
-if (finished) {
-  return IterOutcome.NONE;
-}
+while (state != State.FINISHED) {
+  switch (state) {
+case RIGHT: {
 
-if (!finishedRight) {
-  outcome = handleRightIncoming();
-  if (outcome != null) {
-return outcome;
+  // Can only return NOT_YET
+  IterOutcome outcome = handleRightIncoming();
+  if (outcome != null) {
+return outcome;
+  }
+  break;
+}
+case LEFT: {
+
+  // Can only return NOT_YET
+  IterOutcome outcome = handleLeftIncoming();
+  if (outcome != null) {
+return outcome;
+  }
+  break;
+}
+case WRITE:
+  writeToMetastore();
+  createSummary();
+  state = State.FINISHED;
+  return IterOutcome.OK_NEW_SCHEMA;
+
+case FINISHED:
+  break;
+
+default:
+  throw new IllegalStateException(state.name());
   }
 }
+return IterOutcome.NONE;
+  }
 
+  private IterOutcome handleRightIncoming() {
 outer:
-while (true) {
-  outcome = next(0, left);
+for (;;) {

Review comment:
   Interesting. Which IDE warns? With which warning? Eclipse is fine with 
either syntax. I can perhaps add a warning in Eclipse to match your IDE.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [drill] paul-rogers commented on pull request #2068: DRILL-7717: Support Mongo extended types in V2 JSON loader

[GitBox]

paul-rogers commented on pull request #2068:
URL: https://github.com/apache/drill/pull/2068#issuecomment-623189687


   Added provided schema support for extended types, along with tests.
   
   Rebased on the latest master and resolved conflicts from parallel JSON work.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [drill] paul-rogers commented on a change in pull request #2068: DRILL-7717: Support Mongo extended types in V2 JSON loader

[GitBox]

paul-rogers commented on a change in pull request #2068:
URL: https://github.com/apache/drill/pull/2068#discussion_r419145721



##
File path: 
exec/java-exec/src/main/java/org/apache/drill/exec/store/easy/json/extended/ExtendedTypeFieldFactory.java
##
@@ -0,0 +1,207 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.drill.exec.store.easy.json.extended;
+
+import org.apache.drill.common.types.TypeProtos.MinorType;
+import org.apache.drill.exec.record.metadata.MetadataUtils;
+import org.apache.drill.exec.store.easy.json.loader.BaseFieldFactory;
+import org.apache.drill.exec.store.easy.json.loader.FieldDefn;
+import org.apache.drill.exec.store.easy.json.loader.FieldFactory;
+import org.apache.drill.exec.store.easy.json.loader.JsonLoaderImpl;
+import org.apache.drill.exec.store.easy.json.parser.ElementParser;
+import org.apache.drill.exec.store.easy.json.parser.TokenIterator;
+import org.apache.drill.exec.store.easy.json.parser.ValueParser;
+import org.apache.drill.exec.store.easy.json.values.BinaryValueListener;
+import org.apache.drill.exec.store.easy.json.values.UtcDateValueListener;
+import org.apache.drill.exec.store.easy.json.values.DecimalValueListener;
+import org.apache.drill.exec.store.easy.json.values.IntervalValueListener;
+import org.apache.drill.exec.store.easy.json.values.StrictBigIntValueListener;
+import org.apache.drill.exec.store.easy.json.values.StrictDoubleValueListener;
+import org.apache.drill.exec.store.easy.json.values.StrictIntValueListener;
+import org.apache.drill.exec.store.easy.json.values.StrictStringValueListener;
+import org.apache.drill.exec.store.easy.json.values.TimeValueListener;
+import org.apache.drill.exec.store.easy.json.values.UtcTimestampValueListener;
+
+import com.fasterxml.jackson.core.JsonToken;
+
+public class ExtendedTypeFieldFactory extends BaseFieldFactory {
+
+  public ExtendedTypeFieldFactory(JsonLoaderImpl loader, FieldFactory child) {
+super(loader, child);
+  }
+
+  @Override
+  public ElementParser fieldParser(FieldDefn fieldDefn) {
+ElementParser parser = buildExtendedTypeParser(fieldDefn);
+if (parser == null) {
+  return child.fieldParser(fieldDefn);
+} else {
+  return parser;
+}
+  }
+
+  private ElementParser buildExtendedTypeParser(FieldDefn fieldDefn) {
+
+// Extended types are objects: { "$type": ... }
+// Extended arrays are [ { "$type": ...
+TokenIterator tokenizer = fieldDefn.tokenizer();
+JsonToken token = tokenizer.requireNext();
+ElementParser parser;
+switch (token) {
+  case START_OBJECT:
+parser = extendedTypeParserFor(fieldDefn, false);
+break;
+  case START_ARRAY:
+parser = arrayParserFor(fieldDefn);
+break;
+  default:
+parser = null;
+}
+tokenizer.unget(token);
+return parser;
+  }
+
+  private ElementParser arrayParserFor(FieldDefn fieldDefn) {
+TokenIterator tokenizer = fieldDefn.tokenizer();
+JsonToken token = tokenizer.requireNext();
+if (token != JsonToken.START_OBJECT) {
+  tokenizer.unget(token);
+  return null;
+}
+
+ValueParser element = extendedTypeParserFor(fieldDefn, true);
+tokenizer.unget(token);
+if (element == null) {
+  return null;
+}
+
+return scalarArrayParserFor(element);
+  }
+
+  private BaseExtendedValueParser extendedTypeParserFor(FieldDefn fieldDefn, 
boolean isArray) {
+TokenIterator tokenizer = fieldDefn.tokenizer();
+JsonToken token = tokenizer.peek();
+if (token != JsonToken.FIELD_NAME) {
+  return null;
+}
+
+String key = tokenizer.textValue().trim();
+if (!key.startsWith(ExtendedTypeNames.TYPE_PREFIX)) {
+  return null;
+}
+return parserFor(fieldDefn, key, isArray);
+  }
+
+  private BaseExtendedValueParser parserFor(FieldDefn fieldDefn, String key, 
boolean isArray) {
+switch (key) {
+case ExtendedTypeNames.LONG:
+  return numberLongParser(fieldDefn, isArray);
+case ExtendedTypeNames.DECIMAL:
+  return numberDecimalParser(fieldDefn, isArray);
+case ExtendedTypeNames.DOUBLE:
+  return numberDoubleParser(fieldDefn, isArray);
+case ExtendedTypeNames.INT:
+  return 

Re: compile issue with MapR repo is being worked

[Ted Dunning]

It appears that the certificate issue is resolved.

Can somebody verify this by doing a compilation?

I have to add that based on the number of off-line and on-list pings I got
about this issue I can say that there were quite a few people compiling
Drill on a Sunday morning. That bodes well, I think, for community health.



On Sun, May 3, 2020 at 11:27 AM Ted Dunning  wrote:

>
> I just got word back that the team is looking at the issue.
>
> Not surprisingly, their first look indicates that the issue isn't what it
> appears to be (i.e. not a bad cert)
>
>
>

Drill with No-SQL [was: Cannot Build Drill "exec/Java Execution Engine"]

[Paul Rogers]

Hi Tug,

Glad to hear from you again. Ted's summary is pretty good; here's a bit more 
detail.


Presto is another alternative which seems to have gained the most traction 
outside of the Cloud ecosystem on the one hand, and the Cloudera/HortonWorks 
ecosystem on the other. Presto does, however, demand that you have a schema, 
which is often an obstacle for many applications.

Most folks I've talked to who tried to use Spark for this use case came away 
disappointed. Unlike Drill (or Presto or Impala), Spark wants to start new Java 
processes for each query. Makes great sense for large, complex map/reduce jobs, 
but is a non-starter for small, interactive queries.

Hive also is trying to be an "uber query layer" and has integrations with 
multiple systems. But, Hive's complexity makes Drill look downright simple by 
comparison. Hive also needs an up-front schema.


I've had the opportunity to integrate Drill with two different noSQL engines. 
Getting started is easy, especially if a REST or similar API is available. 
Filter push-down is the next step as otherwise Drill will simply suck all data 
from your DB as it it were a file. We've added some structure in the new HTTP 
reader to make it a bit easier than it used to be to create this kind of filter 
push-down. (The other kind of filter push-down is for partition pruning used 
for files, which you probably won't need.)

Aside from the current MapR repo issues, Drill tends to be much easier to build 
than other systems. Pretty much set up Java and the correct Maven and you're 
good to go. If you run unit tests, there is one additional library to install, 
but the tests themselves tell you you exactly what is needed when they fail the 
first time (which I how I learned about it.)


After that, performance will point the way. For example, does your DB have 
indexes? If so, then you can leverage the work originally done for MapR-DB to 
convey index information to Calcite so it can pick the best execution plan. 
There are specialized operators for index key lookup as well.

All this will get you the basic one-table scan which is often all that no-SQL 
DBs ever need. (Any structure usually appears within each document, rather than 
as joined table as in the RDBMS world.) However, if your DB does need joins, 
you will need something like Calcite to work out the tradeoffs of the various 
join+filter-push plans possible, especially if your DB supports multiple 
indexes. There is no escaping the plan-time complexity of these cases. Calcite 
is big and complex, but it does give you the tools needed to solve these 
problems.

If your DB is to be used to power dashboards (summaries of logs, time series, 
click streams, sales or whatever), you'll soon find you need to provide a 
caching/aggregation layer to avoid banging on your DB each time the dashboard 
refreshes. (Imagine a 1-week dashboard, updated every minute, where only the 
last hour has new data.) Drill becomes very handy as a way of combining data 
from a mostly-static caching layer (data for the last 6 days, say) with your 
live DB (for the last one day, say.)

If you provide a "writer" as well as a "reader", you can use Drill to load your 
DB as well as query it.


Happy to share whatever else I might have learned if you can describe your 
goals in a bit more detail.

Thanks,
- Paul

 

On Sunday, May 3, 2020, 11:25:11 AM PDT, Ted Dunning 
 wrote:  
 
 The compile problem is a problem with the MapR repo (I think). I have
reported it to the folks who can fix it.

Regarding the generic question, I think that Drill is very much a good
choice for putting a SQL layer on a noSQL database.

It is definitely the case that the community is much broader than it used
to be. A number of companies now use Drill in their products which is
one of the best ways to build long-term community.

There are alternatives, of course. All have trade-offs (because we live in
the world):

- Calcite itself (what Drill uses as a SQL parser and optimizer) can be
used, but you have to provide an execution framework and you wind up with
something that only works for your engine and is unlikely to support
parallel operations. Calcite is used by lots of projects, though, so it is
has a very broad base of support.

- Spark SQL is fairly easy to extend (from what I hear from friends) but
the optimizer doesn't deal well with complicated tradeoffs (precisely
because it is fairly simple). You also wind up with the baggage of spark
which could be good or bad. You would get some parallelism, though. I don't
think that Spark SQL handles complex objects, however.

- Postgres has a long history of having odd things grafted onto it. I know
little about this other than seeing the results. Extending Postgres would
not likely give you any parallelism, but there might be a way to support
complex objects through Postgres JSON object support.




On Sun, May 3, 2020 at 11:09 AM Tugdual Grall  wrote:

> Hello
>
> It has been a long time since I used 

compile issue with MapR repo is being worked

[Ted Dunning]

I just got word back that the team is looking at the issue.

Not surprisingly, their first look indicates that the issue isn't what it
appears to be (i.e. not a bad cert)

Re: Cannot Build Drill "exec/Java Execution Engine"

[Ted Dunning]

The compile problem is a problem with the MapR repo (I think). I have
reported it to the folks who can fix it.

Regarding the generic question, I think that Drill is very much a good
choice for putting a SQL layer on a noSQL database.

It is definitely the case that the community is much broader than it used
to be. A number of companies now use Drill in their products which is
one of the best ways to build long-term community.

There are alternatives, of course. All have trade-offs (because we live in
the world):

- Calcite itself (what Drill uses as a SQL parser and optimizer) can be
used, but you have to provide an execution framework and you wind up with
something that only works for your engine and is unlikely to support
parallel operations. Calcite is used by lots of projects, though, so it is
has a very broad base of support.

- Spark SQL is fairly easy to extend (from what I hear from friends) but
the optimizer doesn't deal well with complicated tradeoffs (precisely
because it is fairly simple). You also wind up with the baggage of spark
which could be good or bad. You would get some parallelism, though. I don't
think that Spark SQL handles complex objects, however.

- Postgres has a long history of having odd things grafted onto it. I know
little about this other than seeing the results. Extending Postgres would
not likely give you any parallelism, but there might be a way to support
complex objects through Postgres JSON object support.




On Sun, May 3, 2020 at 11:09 AM Tugdual Grall  wrote:

> Hello
>
> It has been a long time since I used Drill!
>
> I wanted to build it to start to work on a new datasource,.
>
> But when run  "mvn clean install", I hit the exception below.
>
> => Can somebody help?
>
> => This bring me to a generic question, if I want to expose a NoSQL
> database using SQL/JDBC/ODBC for Analytics purposes, is Drill the best
> option? or I should look at something else?
>
>
> Thanks!
>
> 
> [INFO] exec/Java Execution Engine . FAILURE [
>  0.676 s]
>
> [ERROR] Failed to execute goal on project drill-java-exec: Could not
> resolve dependencies
> for project org.apache.drill.exec:drill-java-exec:jar:1.18.0-SNAPSHOT:
> Failed to collect dependencies at org.kohsuke:libpam4j:jar:1.8-rev2: Failed
> to read artifact descriptor for org.kohsuke:libpam4j:jar:1.8-rev2: Could
> not transfer artifact org.kohsuke:libpam4j:pom:1.8-rev2 from/to
> mapr-releases (http://repository.mapr.com/maven/): Transfer failed for
>
> http://repository.mapr.com/maven/org/kohsuke/libpam4j/1.8-rev2/libpam4j-1.8-rev2.pom
> 500 Proxy Error -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
>
> http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR]   mvn  -rf :drill-java-exec
>

Cannot Build Drill "exec/Java Execution Engine"

[Tugdual Grall]

Hello

It has been a long time since I used Drill!

I wanted to build it to start to work on a new datasource,.

But when run  "mvn clean install", I hit the exception below.

=> Can somebody help?

=> This bring me to a generic question, if I want to expose a NoSQL
database using SQL/JDBC/ODBC for Analytics purposes, is Drill the best
option? or I should look at something else?


Thanks!


[INFO] exec/Java Execution Engine . FAILURE [
 0.676 s]

[ERROR] Failed to execute goal on project drill-java-exec: Could not
resolve dependencies
for project org.apache.drill.exec:drill-java-exec:jar:1.18.0-SNAPSHOT:
Failed to collect dependencies at org.kohsuke:libpam4j:jar:1.8-rev2: Failed
to read artifact descriptor for org.kohsuke:libpam4j:jar:1.8-rev2: Could
not transfer artifact org.kohsuke:libpam4j:pom:1.8-rev2 from/to
mapr-releases (http://repository.mapr.com/maven/): Transfer failed for
http://repository.mapr.com/maven/org/kohsuke/libpam4j/1.8-rev2/libpam4j-1.8-rev2.pom
500 Proxy Error -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the
command
[ERROR]   mvn  -rf :drill-java-exec

Re: More CI Issues

[Ted Dunning]

I have asked the MapR team to look into the certificate issue.



On Sun, May 3, 2020 at 8:03 AM Charles Givre  wrote:

> Hello all,
> In a recent PR that had nothing to do with this, I saw that the CI is now
> failing due to the following error.  I did some digging and found that the
> URL http://repository.mapr.com/maven/ 
> is no longer accessible.  However with SSL
> https://repository.mapr.com/maven/ 
> IS available but with bad certificates.
>
> I'm not a maven with maven, but is there some way to easily fix this so
> that Drill isn't trying to pull from non-existent or broken MapR repos?
> Best,
> -- C
>
>
> [ERROR] Failed to execute goal on project drill-java-exec: Could not
> resolve dependencies for project
> org.apache.drill.exec:drill-java-exec:jar:1.18.0-SNAPSHOT: Failed to
> collect dependencies at org.kohsuke:libpam4j:jar:1.8-rev2: Failed to read
> artifact descriptor for org.kohsuke:libpam4j:jar:1.8-rev2: Could not
> transfer artifact org.kohsuke:libpam4j:pom:1.8-rev2 from/to mapr-releases (
> http://repository.mapr.com/maven/): Transfer failed for
> http://repository.mapr.com/maven/org/kohsuke/libpam4j/1.8-rev2/libpam4j-1.8-rev2.pom
> 500 Proxy Error -> [Help 1]
> 1094
>  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640588163#step:6:1094>[ERROR]
>
> 1095
>  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640588163#step:6:1095>[ERROR]
> To see the full stack trace of the errors, re-run Maven with the -e switch.
> 1096
>  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640588163#step:6:1096>[ERROR]
> Re-run Maven using the -X switch to enable full debug logging.
> 1097
>  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640588163#step:6:1097>[ERROR]
>
> 1098
>  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640588163#step:6:1098>[ERROR]
> For more information about the errors and possible solutions, please read
> the following articles:
> 1099
>  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640588163#step:6:1099>[ERROR]
> [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
> 1100
>  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640588163#step:6:1100>[ERROR]
>
> 1101
>  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640588163#step:6:1101>[ERROR]
> After correcting the problems, you can resume the build with the command
> 1102
>  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640588163#step:6:1102>[ERROR]
>  mvn  -rf :drill-java-exec
> 1103
>  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640588163#step:6:1103>##[error]Process
> completed with exit code 1.

Re: More CI Issues

[Vova Vysotskyi]

Hi Charles,

Here is a Jira for migrating repositories to https: DRILL-7270
, but as you may see from
its comment, the repository owner was informed about certificates issues.
So it looks like some work for fixing this issue is in the progress and it
caused the unavailability of the repository.

Hope it will be fixed soon.

Kind regards,
Volodymyr Vysotskyi


On Sun, May 3, 2020 at 6:14 PM Charles Givre  wrote:

> One more thing...
> I tried changing the HTTP to HTTPS (which we should do anyway) and now it
> is getting certificate errors:
>
> [ERROR] Failed to execute goal on project drill-java-exec: Could not
> resolve dependencies for project
> org.apache.drill.exec:drill-java-exec:jar:1.18.0-SNAPSHOT: Failed to
> collect dependencies at org.kohsuke:libpam4j:jar:1.8-rev2: Failed to read
> artifact descriptor for org.kohsuke:libpam4j:jar:1.8-rev2: Could not
> transfer artifact org.kohsuke:libpam4j:pom:1.8-rev2 from/to mapr-releases (
> https://repository.mapr.com/maven/): Transfer failed for
> https://repository.mapr.com/maven/org/kohsuke/libpam4j/1.8-rev2/libpam4j-1.8-rev2.pom:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target -> [Help 1]
> 35540
>  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640659179#step:6:35540>[ERROR]
>
> 35541
>  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640659179#step:6:35541>[ERROR]
> To see the full stack trace of the errors, re-run Maven with the -e switch.
> 35542
>  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640659179#step:6:35542>[ERROR]
> Re-run Maven using the -X switch to enable full debug logging.
> 35543
>  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640659179#step:6:35543>[ERROR]
>
> 35544
>  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640659179#step:6:35544>[ERROR]
> For more information about the errors and possible solutions, please read
> the following articles:
> 35545
>  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640659179#step:6:35545>[ERROR]
> [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
> 35546
>  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640659179#step:6:35546>[ERROR]
>
> 35547
>  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640659179#step:6:35547>[ERROR]
> After correcting the problems, you can resume the build with the command
> 35548
>  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640659179#step:6:35548>[ERROR]
>  mvn  -rf :drill-java-exec
> 35549
>  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640659179#step:6:35549>##[error]Process
> completed with exit code 1.
>
>
>
> > On May 3, 2020, at 11:02 AM, Charles Givre  wrote:
> >
> > Hello all,
> > In a recent PR that had nothing to do with this, I saw that the CI is
> now failing due to the following error.  I did some digging and found that
> the URL http://repository.mapr.com/maven/ <
> http://repository.mapr.com/maven/> is no longer accessible.  However with
> SSL https://repository.mapr.com/maven/ 
> IS available but with bad certificates.
> >
> > I'm not a maven with maven, but is there some way to easily fix this so
> that Drill isn't trying to pull from non-existent or broken MapR repos?
> > Best,
> > -- C
> >
> >
> > [ERROR] Failed to execute goal on project drill-java-exec: Could not
> resolve dependencies for project
> org.apache.drill.exec:drill-java-exec:jar:1.18.0-SNAPSHOT: Failed to
> collect dependencies at org.kohsuke:libpam4j:jar:1.8-rev2: Failed to read
> artifact descriptor for org.kohsuke:libpam4j:jar:1.8-rev2: Could not
> transfer artifact org.kohsuke:libpam4j:pom:1.8-rev2 from/to mapr-releases (
> http://repository.mapr.com/maven/ ):
> Transfer failed for
> http://repository.mapr.com/maven/org/kohsuke/libpam4j/1.8-rev2/libpam4j-1.8-rev2.pom
> <
> http://repository.mapr.com/maven/org/kohsuke/libpam4j/1.8-rev2/libpam4j-1.8-rev2.pom>
> 500 Proxy Error -> [Help 1]
> > 1094
> >  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640588163#step:6:1094>[ERROR]
>
> > 1095
> >  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640588163#step:6:1095>[ERROR]
> To see the full stack trace of the errors, re-run Maven with the -e switch.
> > 1096
> >  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640588163#step:6:1096>[ERROR]
> Re-run Maven using the -X switch to enable full debug logging.
> > 1097
> >  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640588163#step:6:1097>[ERROR]
>
> > 1098
> >  <
> https://github.com/apache/drill/pull/2067/checks?check_run_id=640588163#step:6:1098>[ERROR]
> For more 

Re: More CI Issues

[Charles Givre]

One more thing... 
I tried changing the HTTP to HTTPS (which we should do anyway) and now it is 
getting certificate errors:

[ERROR] Failed to execute goal on project drill-java-exec: Could not resolve 
dependencies for project 
org.apache.drill.exec:drill-java-exec:jar:1.18.0-SNAPSHOT: Failed to collect 
dependencies at org.kohsuke:libpam4j:jar:1.8-rev2: Failed to read artifact 
descriptor for org.kohsuke:libpam4j:jar:1.8-rev2: Could not transfer artifact 
org.kohsuke:libpam4j:pom:1.8-rev2 from/to mapr-releases 
(https://repository.mapr.com/maven/): Transfer failed for 
https://repository.mapr.com/maven/org/kohsuke/libpam4j/1.8-rev2/libpam4j-1.8-rev2.pom:
 sun.security.validator.ValidatorException: PKIX path building failed: 
sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
valid certification path to requested target -> [Help 1]
35540
 
[ERROR]
 
35541
 
[ERROR]
 To see the full stack trace of the errors, re-run Maven with the -e switch.
35542
 
[ERROR]
 Re-run Maven using the -X switch to enable full debug logging.
35543
 
[ERROR]
 
35544
 
[ERROR]
 For more information about the errors and possible solutions, please read the 
following articles:
35545
 
[ERROR]
 [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
35546
 
[ERROR]
 
35547
 
[ERROR]
 After correcting the problems, you can resume the build with the command
35548
 
[ERROR]
   mvn  -rf :drill-java-exec
35549
 
##[error]Process
 completed with exit code 1.



> On May 3, 2020, at 11:02 AM, Charles Givre  wrote:
> 
> Hello all, 
> In a recent PR that had nothing to do with this, I saw that the CI is now 
> failing due to the following error.  I did some digging and found that the 
> URL http://repository.mapr.com/maven/  is 
> no longer accessible.  However with SSL https://repository.mapr.com/maven/ 
>  IS available but with bad certificates.  
> 
> I'm not a maven with maven, but is there some way to easily fix this so that 
> Drill isn't trying to pull from non-existent or broken MapR repos?  
> Best, 
> -- C
> 
> 
> [ERROR] Failed to execute goal on project drill-java-exec: Could not resolve 
> dependencies for project 
> org.apache.drill.exec:drill-java-exec:jar:1.18.0-SNAPSHOT: Failed to collect 
> dependencies at org.kohsuke:libpam4j:jar:1.8-rev2: Failed to read artifact 
> descriptor for org.kohsuke:libpam4j:jar:1.8-rev2: Could not transfer artifact 
> org.kohsuke:libpam4j:pom:1.8-rev2 from/to mapr-releases 
> (http://repository.mapr.com/maven/ ): 
> Transfer failed for 
> http://repository.mapr.com/maven/org/kohsuke/libpam4j/1.8-rev2/libpam4j-1.8-rev2.pom
>  
> 
>  500 Proxy Error -> [Help 1]
> 1094
>  
> [ERROR]
>  
> 1095
>  
> [ERROR]
>  To see the full stack trace of the errors, re-run Maven with the -e switch.
> 1096
>  
> [ERROR]
>  Re-run Maven using the -X switch to enable full debug logging.
> 1097
>  
> [ERROR]
>  
> 1098
>  
> [ERROR]
>  For more information about the errors and possible solutions, please read 
> the following articles:
> 1099
>  
> [ERROR]
>  [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
>  
> 
> 1100
>  
> [ERROR]
>  
> 1101
>  
> 

More CI Issues

[Charles Givre]

Hello all, 
In a recent PR that had nothing to do with this, I saw that the CI is now 
failing due to the following error.  I did some digging and found that the URL 
http://repository.mapr.com/maven/  is no 
longer accessible.  However with SSL https://repository.mapr.com/maven/ 
 IS available but with bad certificates.  

I'm not a maven with maven, but is there some way to easily fix this so that 
Drill isn't trying to pull from non-existent or broken MapR repos?  
Best, 
-- C


[ERROR] Failed to execute goal on project drill-java-exec: Could not resolve 
dependencies for project 
org.apache.drill.exec:drill-java-exec:jar:1.18.0-SNAPSHOT: Failed to collect 
dependencies at org.kohsuke:libpam4j:jar:1.8-rev2: Failed to read artifact 
descriptor for org.kohsuke:libpam4j:jar:1.8-rev2: Could not transfer artifact 
org.kohsuke:libpam4j:pom:1.8-rev2 from/to mapr-releases 
(http://repository.mapr.com/maven/): Transfer failed for 
http://repository.mapr.com/maven/org/kohsuke/libpam4j/1.8-rev2/libpam4j-1.8-rev2.pom
 500 Proxy Error -> [Help 1]
1094
 
[ERROR]
 
1095
 
[ERROR]
 To see the full stack trace of the errors, re-run Maven with the -e switch.
1096
 
[ERROR]
 Re-run Maven using the -X switch to enable full debug logging.
1097
 
[ERROR]
 
1098
 
[ERROR]
 For more information about the errors and possible solutions, please read the 
following articles:
1099
 
[ERROR]
 [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
1100
 
[ERROR]
 
1101
 
[ERROR]
 After correcting the problems, you can resume the build with the command
1102
 
[ERROR]
   mvn  -rf :drill-java-exec
1103
 
##[error]Process
 completed with exit code 1.