Re: Відп.: Start embedded Drill on JDBC connection

2021-11-05 Thread James Turton 
I like the idea, just can't wrap my head around what the pom file would 
need to look like.


On 2021/11/05 23:34, Rumar, Maksym wrote:

Yes, right. Only import the Drill JDBC dependence into the pom file. Embedded 
Drill could start on the step of establishing connection and end on the 
connection close.

I understand that it is too expensive operation, but it is need for simplifying 
of start up. With it, we may get 3 ways of bootstrapping Drill: embedded, 
standalone embedded and distributed. And each one has it's use cases.

Від: luoc 
Надіслано: 5 листопада 2021 р. 15:45
Кому: dev@drill.apache.org 
Тема: Re: Start embedded Drill on JDBC connection


Hi Maksym,
Thanks for the idea. In your opinion, there is no longer need to extract the 
binary tar.gz, and start the Drillbit? Only import the Drill JDBC dependence 
into your pom file? If so, what is the lifecycle of embedded Drill?


在 2021年11月5日，21:06，Rumar, Maksym  写道：

Hi all drill devs and users!

I have one thought about embedded Drill and would like to discuss it with you.
Drill JDBC driver may start embedded Drill by self (if to make some 
machinations with dependencies) and I think that it is a very useful feature. 
With this opportunity, all people not familiar with Drill may try it in so 
convenient and simple way: add dependencies in pom and just write a few code 
lines of JDBC to make a test. This will leverage the level of entry to Drill 
and may make Drill more famous.

This feature is actually not supported for a now and blocked with a simple 
check
 in Drill JDBC code. What do you think about it? What if we add support for it and 
improve it by adding a convenient way for this case to set up storage plugins?

Regards,
Maksym

Відп.: Start embedded Drill on JDBC connection

2021-11-05 Thread Rumar, Maksym 
Yes, right. Only import the Drill JDBC dependence into the pom file. Embedded 
Drill could start on the step of establishing connection and end on the 
connection close.

I understand that it is too expensive operation, but it is need for simplifying 
of start up. With it, we may get 3 ways of bootstrapping Drill: embedded, 
standalone embedded and distributed. And each one has it's use cases.

Від: luoc 
Надіслано: 5 листопада 2021 р. 15:45
Кому: dev@drill.apache.org 
Тема: Re: Start embedded Drill on JDBC connection


Hi Maksym,
Thanks for the idea. In your opinion, there is no longer need to extract the 
binary tar.gz, and start the Drillbit? Only import the Drill JDBC dependence 
into your pom file? If so, what is the lifecycle of embedded Drill?

> 在 2021年11月5日，21:06，Rumar, Maksym  写道：
>
> Hi all drill devs and users!
>
> I have one thought about embedded Drill and would like to discuss it with you.
> Drill JDBC driver may start embedded Drill by self (if to make some 
> machinations with dependencies) and I think that it is a very useful feature. 
> With this opportunity, all people not familiar with Drill may try it in so 
> convenient and simple way: add dependencies in pom and just write a few code 
> lines of JDBC to make a test. This will leverage the level of entry to Drill 
> and may make Drill more famous.
>
> This feature is actually not supported for a now and blocked with a simple 
> check
>  in Drill JDBC code. What do you think about it? What if we add support for 
> it and improve it by adding a convenient way for this case to set up storage 
> plugins?
>
> Regards,
> Maksym

[GitHub] [drill] lgtm-com[bot] commented on pull request #2282: DRILL-7978: Fixed Width Format Plugin

2021-11-05 Thread GitBox 


lgtm-com[bot] commented on pull request #2282:
URL: https://github.com/apache/drill/pull/2282#issuecomment-961938801






-- 
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.

To unsubscribe, e-mail: dev-unsubscr...@drill.apache.org

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

[GitHub] [drill] vdiravka commented on pull request #2364: DRILL-8037: Add V2 JSON Format Plugin based on EVF

2021-11-05 Thread GitBox 


vdiravka commented on pull request #2364:
URL: https://github.com/apache/drill/pull/2364#issuecomment-961583471


   @paul-rogers I've cherry-picked commit from your 
[rev2](https://github.com/paul-rogers/drill/tree/DRILL-6953-rev2) branch. 
Didn't get all of them, because of big code conflicts and some of them are 
outdated.
   Draft until all tests from 
[rev2](https://github.com/paul-rogers/drill/tree/DRILL-6953-rev2) are enabled. 


-- 
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.

To unsubscribe, e-mail: dev-unsubscr...@drill.apache.org

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

[GitHub] [drill] paul-rogers commented on pull request #2359: DRILL-8028: Add PDF Format Plugin

2021-11-05 Thread GitBox 


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


   @cgivre, @dzamo raise good points. So, what is Drill today? Is it still 
primarily used for distributed queries at scale? Or, as a handy desktop tool 
for data scientists? Probably both. The problem is, a tool that tries to be 
both a desert topping and a floor wax (let's see how old the readers are with 
this one), ends up being good at neither.
   
   One approach, if we had resources, would be to create a Drill Desktop that 
is optimized for that case and encourages all kinds of specialized data 
connectors. Create an easy way to define those connectors (YAML files created 
by specialized web apps?) Ensure Drill has good integration with Jupyter and 
the other usual suspects.
   
   Another approach, if we had resources, is the oft-discussed idea of 
separating the less-common plugins from the Drill core. Work started on this: 
to create an extension mechanism that made this possible. (Today, most plugins 
need quite a bit of Drill internal code.)
   
   So, no harm in adding the PDF reader, but I expect usage will be pretty 
limited just because, for the folks that need it, configuration will be too 
hard. Better would be a Python or Spark job that extracts the data into a CSV 
file, then query the CSV file with Drill. Each step could be debugged easily. I 
can't imagine anyone will want to debug their PDF extraction using Drill's 
overly generous Java stack traces... 


-- 
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.

To unsubscribe, e-mail: dev-unsubscr...@drill.apache.org

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

[GitHub] [drill] vdiravka edited a comment on pull request #2349: Introducing lgtm.yml file

2021-11-05 Thread GitBox 


vdiravka edited a comment on pull request #2349:
URL: https://github.com/apache/drill/pull/2349#issuecomment-958981840






-- 
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.

To unsubscribe, e-mail: dev-unsubscr...@drill.apache.org

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

[GitHub] [drill] lgtm-com[bot] commented on pull request #2282: DRILL-7978: Fixed Width Format Plugin

2021-11-05 Thread GitBox 


lgtm-com[bot] commented on pull request #2282:
URL: https://github.com/apache/drill/pull/2282#issuecomment-961938801






-- 
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.

To unsubscribe, e-mail: dev-unsubscr...@drill.apache.org

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

[GitHub] [drill] vdiravka commented on pull request #2364: DRILL-8037: Add V2 JSON Format Plugin based on EVF

2021-11-05 Thread GitBox 


vdiravka commented on pull request #2364:
URL: https://github.com/apache/drill/pull/2364#issuecomment-961583471


   @paul-rogers I've cherry-picked commit from your 
[rev2](https://github.com/paul-rogers/drill/tree/DRILL-6953-rev2) branch. 
Didn't get all of them, because of big code conflicts and some of them are 
outdated.
   Draft until all tests from 
[rev2](https://github.com/paul-rogers/drill/tree/DRILL-6953-rev2) are enabled. 


-- 
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.

To unsubscribe, e-mail: dev-unsubscr...@drill.apache.org

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

[GitHub] [drill] paul-rogers commented on pull request #2359: DRILL-8028: Add PDF Format Plugin

2021-11-05 Thread GitBox 


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


   @cgivre, @dzamo raise good points. So, what is Drill today? Is it still 
primarily used for distributed queries at scale? Or, as a handy desktop tool 
for data scientists? Probably both. The problem is, a tool that tries to be 
both a desert topping and a floor wax (let's see how old the readers are with 
this one), ends up being good at neither.
   
   One approach, if we had resources, would be to create a Drill Desktop that 
is optimized for that case and encourages all kinds of specialized data 
connectors. Create an easy way to define those connectors (YAML files created 
by specialized web apps?) Ensure Drill has good integration with Jupyter and 
the other usual suspects.
   
   Another approach, if we had resources, is the oft-discussed idea of 
separating the less-common plugins from the Drill core. Work started on this: 
to create an extension mechanism that made this possible. (Today, most plugins 
need quite a bit of Drill internal code.)
   
   So, no harm in adding the PDF reader, but I expect usage will be pretty 
limited just because, for the folks that need it, configuration will be too 
hard. Better would be a Python or Spark job that extracts the data into a CSV 
file, then query the CSV file with Drill. Each step could be debugged easily. I 
can't imagine anyone will want to debug their PDF extraction using Drill's 
overly generous Java stack traces... 


-- 
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.

To unsubscribe, e-mail: dev-unsubscr...@drill.apache.org

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

[GitHub] [drill] lgtm-com[bot] commented on pull request #2282: DRILL-7978: Fixed Width Format Plugin

2021-11-05 Thread GitBox 


lgtm-com[bot] commented on pull request #2282:
URL: https://github.com/apache/drill/pull/2282#issuecomment-962044746


   This pull request **introduces 2 alerts** when merging 
9b95c45f7f5ddbb7543c89a1efac99bda0ebff8c into 
52838ef26e5e3e6b4461c2c656ffada0c64c9e88 - [view on 
LGTM.com](https://lgtm.com/projects/g/apache/drill/rev/pr-7d8671f78491ffc2026ea94d10c597de912e7eec)
   
   **new alerts:**
   
   * 2 for Unused format argument


-- 
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.

To unsubscribe, e-mail: dev-unsubscr...@drill.apache.org

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

[GitHub] [drill] lgtm-com[bot] commented on pull request #2282: DRILL-7978: Fixed Width Format Plugin

2021-11-05 Thread GitBox 


lgtm-com[bot] commented on pull request #2282:
URL: https://github.com/apache/drill/pull/2282#issuecomment-961938801


   This pull request **introduces 2 alerts** when merging 
9d66f9114ab27429a8366d1d71b15f638574dc45 into 
52838ef26e5e3e6b4461c2c656ffada0c64c9e88 - [view on 
LGTM.com](https://lgtm.com/projects/g/apache/drill/rev/pr-d2e0dd9a19bfba83486250ec80ec4737d67ff38e)
   
   **new alerts:**
   
   * 2 for Unused format argument


-- 
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.

To unsubscribe, e-mail: dev-unsubscr...@drill.apache.org

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

Re: Start embedded Drill on JDBC connection

2021-11-05 Thread luoc 

Hi Maksym,
Thanks for the idea. In your opinion, there is no longer need to extract the 
binary tar.gz, and start the Drillbit? Only import the Drill JDBC dependence 
into your pom file? If so, what is the lifecycle of embedded Drill?

> 在 2021年11月5日，21:06，Rumar, Maksym  写道：
> 
> Hi all drill devs and users!
> 
> I have one thought about embedded Drill and would like to discuss it with you.
> Drill JDBC driver may start embedded Drill by self (if to make some 
> machinations with dependencies) and I think that it is a very useful feature. 
> With this opportunity, all people not familiar with Drill may try it in so 
> convenient and simple way: add dependencies in pom and just write a few code 
> lines of JDBC to make a test. This will leverage the level of entry to Drill 
> and may make Drill more famous.
> 
> This feature is actually not supported for a now and blocked with a simple 
> check
>  in Drill JDBC code. What do you think about it? What if we add support for 
> it and improve it by adding a convenient way for this case to set up storage 
> plugins?
> 
> Regards,
> Maksym

Start embedded Drill on JDBC connection

2021-11-05 Thread Rumar, Maksym 
Hi all drill devs and users!

I have one thought about embedded Drill and would like to discuss it with you.
Drill JDBC driver may start embedded Drill by self (if to make some 
machinations with dependencies) and I think that it is a very useful feature. 
With this opportunity, all people not familiar with Drill may try it in so 
convenient and simple way: add dependencies in pom and just write a few code 
lines of JDBC to make a test. This will leverage the level of entry to Drill 
and may make Drill more famous.

This feature is actually not supported for a now and blocked with a simple 
check
 in Drill JDBC code. What do you think about it? What if we add support for it 
and improve it by adding a convenient way for this case to set up storage 
plugins?

Regards,
Maksym

Re: webUI Bug

2021-11-05 Thread Ted Dunning 
Nathan,

I think you pasted some images into your message. They didn't make it
through to the mailing list.

Can you select text instead of images? Or push the images to a public place
like imgur?


On Thu, Nov 4, 2021 at 11:31 PM Caballero, Nathan (Volpe)
 wrote:

> Hello,
>
>
>
> I continue to experience a bug on the webUI where if any number is filled
> into the ‘Limit results to’ field, the following error is met. The query
> runs perfectly so long as any value filled out in this field is deleted.
> This bug occurs whether the field is ‘checked’ or ‘unchecked’.
>
>
>
> Thank You
>
>
>
>

webUI Bug

2021-11-05 Thread Caballero, Nathan (Volpe) 
Hello,

I continue to experience a bug on the webUI where if any number is filled into 
the 'Limit results to' field, the following error is met. The query runs 
perfectly so long as any value filled out in this field is deleted. This bug 
occurs whether the field is 'checked' or 'unchecked'.

Thank You

[cid:image001.png@01D7D15F.C8BAE9B0]
[cid:image002.png@01D7D160.32917CA0]