Right now, you’re the first user to ask for a runtime module. The cost:benefit doesn’t justify it yet.
Regarding Guava. We test Calcite against a wide range of Guava versions. Use your own version (anything between 13 and 20) and Calcite won’t mind. You’re right that SqlFunctions isn’t as clean as I thought it was. The use of Avatica stuff like ByteString doesn’t concern me: they’re small, runtime classes. DataContext pulls in some more dependencies (like SchemaPlus) so we should deal with that. Can you please log a JIRA case to track all this? Julian > On Aug 5, 2016, at 6:32 PM, Jungtaek Lim <[email protected]> wrote: > > Hi Julian, > > Thanks for the quick answer. > > Looking at SqlFunctions in master branch, it depends on various libraries > including avatica and linq4j, and also refers outside of runtime package of > calcite. I could copy that classes and transitive imported classes as well, > but I'm not sure other projects were doing same things. > > If calcite project maintains calcite-runtime module with smallest > dependencies that would be awesome for users. I'm trying to avoid > adding calcite-core as dependency since it depends on Guava, the > problematic thing of dependency hell. > > Thanks, > Jungtaek Lim (HeartSaVioR) > > On Saturday, August 6, 2016, Julian Hyde <[email protected] > <mailto:[email protected]>> wrote: > >> We didn’t really consider this when we designed Storm - Calcite >> integration. But the good news is that SqlFunctions is a smallish class >> with almost no dependencies. It, along with the rest of the >> org.apache.calcite.runtime package, could in principle be copied into >> Storm. (I’m not keen on creating a new calcite-runtime.jar but I could be >> persuaded if someone made a strong case.) >> >>> On Aug 5, 2016, at 12:34 AM, Jungtaek Lim <[email protected] >> <javascript:;>> wrote: >>> >>> Hi devs, >>> >>> I'm newbie of Calcite so I'd first say sorry for the ignorance if it's >>> newbie question. >>> >>> I'm working on Storm SQL which uses Calcite to compile SQL to topology. >>> Current implementation uses SqlFunctions to cover some operators so >>> calcite-core and transitive dependencies are needed even though compiled >>> topology in runtime. >>> >>> So I'd like to see what's preferred way of handling this. Is it common to >>> add calcite-core to dependency in runtime, or is it common for individual >>> projects to have their own similar classes? >>> >>> Thanks in advance, >>> Jungtaek Lim (HeartSaVioR) >> >> > > -- > Name : Jungtaek Lim > Blog : http://medium.com/@heartsavior <http://medium.com/@heartsavior> > Twitter : http://twitter.com/heartsavior <http://twitter.com/heartsavior> > LinkedIn : http://www.linkedin.com/in/heartsavior > <http://www.linkedin.com/in/heartsavior>
