drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <jh...@apache.org>
Subject Re: Thinking about Drill 2.0
Date Fri, 09 Jun 2017 22:38:43 GMT

> On Jun 5, 2017, at 11:59 AM, Paul Rogers <progers@mapr.com> wrote:
> Similarly, the storage plugin API exposes details of Calcite (which seems to evolve with
each new version), exposes value vector implementations, and so on. A cleaner, simpler, more
isolated API will allow storage plugins to be built faster, but will also isolate them from
Drill internals changes. Without isolation, each change to Drill internals would require plugin
authors to update their plugin before Drill can be released.

Sorry you’re getting burned by Calcite changes. We try to minimize impact, but sometimes
it’s difficult to see what you’re breaking.

I like the goal of a stable storage plugin API. Maybe it’s something Drill and Calcite can
collaborate on? Much of the DNA of an adapter is independent of the engine that will consume
the data (Drill or otherwise) - it concerns how to create a connection, getting metadata,
and pushing down logical operations, and generating queries in the target system’s query
language. Calcite and Drill ought to be able to share that part, rather than maintaining separate
collections of adapters.


View raw message