Could be a long term solution? Is there any other reason which prevents us using Calcite?
ling miao <lingm...@apache.org> 于2020年10月27日周二 下午8:02写道： > Hi Duo, > > Using calcite directly will definitely not work, which means that the query > analysis + planning are rewritten. > But maybe we can use other parser tools to replace it, or something > similar. > However, it is estimated that the amount of change for this solution. > ...(｡•ˇ‸ˇ•｡) > ... > > Ling Miao > > 张铎(Duo Zhang) <palomino...@gmail.com> 于2020年10月27日周二 下午6:34写道： > > > I think this is used to generate the SQL parser? Is it possible to use > > Calcite directly? > > > > ling miao <lingm...@apache.org> 于2020年10月26日周一 下午7:38写道： > > > > > Hi, > > > > > > Currently, some fe dependencies that we rely on are not in the maven > > repo. > > > For example, cup-maven-plugin and java-cup are located at the Cloudera > > > 3rd-P. > > > This will lead to the risk that our code will not be compiled when the > > > third-party repo changes. > > > > > > I have also tried whether it is possible to replace these dependencies > > > with other packages or versions, but unfortunately the only thing we > can > > > use at the moment is this. > > > > > > So I propose whether we can maintain these jar packages in our own repo > > to > > > ensure that they can be found every time we compile? > > > > > > Or do you have any better solutions? > > > > > > Ling Miao > > > > > >
