> On Jun 5, 2017, at 11:59 AM, Paul Rogers <prog...@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. Julian
