drill-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Derich <carlosder...@gmail.com>
Subject Re: [DISCUSSION] current project state
Date Mon, 27 Aug 2018 16:04:19 GMT
Hello guys,

Thanks for bringing up this discussion, I may be a little bit late but I
would like to add an use case I've been through recently.

I think Drill should be able to use ZK for storing session's data. In a
multiple Drillbit scenario, if a second Drillbit receives a request with a
session token attached, it should try to retrieve that session from ZK
before generating a new session. I have seen this topic pop up every now
and then, I'd be happy to work on it as a first contribution if we decide
how this should work.

I would also like to add that we could try focus on improvements on
documentation ? more specifically on docs that currently do not exist and
also for writing custom storage plugins. I had to work recently on a custom
storage plugin for GeoJSON files and I think the only resource I could find
on this was Charle's log-file plugin (
https://github.com/cgivre/drill-logfile-plugin) which I am incredible
grateful for. I would be more than happy to work on these docs.

Derich.

On Sun, Aug 19, 2018 at 4:49 AM Uwe L. Korn <uwelk@xhochy.com> wrote:

> Hello Arina
>
> On Tue, Aug 14, 2018, at 4:08 PM, Arina Yelchiyeva wrote:
> > 3. Drill vs Arrow is the topic I heard since I have started working with
> > Drill. But so far nobody dared to tackle it. I would suspect Drill first
> > would have to contribute changes in Arrow to be able to migrate which
> could
> > be a show-stopper if Arrow community does not accept them.
>
> What would the changes that need to go into Arrow to make it usable for
> Drill? I suspect that many of them should also align with the Arrow
> project. Especially as the Java code of Arrow started out from Drill's
> ValueVector code. If you already know some of the issues, it would be
> really helpful to open tickets in the ARROW JIRA (feel free to add a drill
> label to them, so one can search for them). Even if there is no plan to
> implement them currently, it definitely helps us Arrow developers in
> visibility what users of the Arrow library need / prevent from adoption.
>
> Uwe
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message