A sql validation error when a statement is being prepared (say by a jdbc server) is really an error, and I think it should be logged.
However when such exceptions occur during tests such as SqlValidatorTest they are clearly not errors - they are expected behavior. So ideally they would not be logged or printed to the screen. Is there a way to achieve both of the above? I agree with your instinct that the tests are currently much too verbose. Julian > On Aug 29, 2018, at 12:01 AM, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> > wrote: > > Hi, > > I would like to hear if there are reasons not to merge CALCITE-2463/PR797 > It is a trivial change, the build is green, and I see no comments (==> that > sounds like an approval). > > The issue is CalciteException and SqlValidatorException always log, and it > clutters build logs for no reason. > > The solution is to print the errors in calcite.debug=true mode only. > There's alternative option to eliminate LOGGER.error(toString()); > altogether, and I'm +0.5 for that. > > I am sure ERROR logs should be dedicated to true errors. Fake errors like > Calite produces now do not belong to error logs. > > The issue does impact me: > 1) SqlAdvisor always logs "errors", however it is SqlAdvisor that crafts > invalid SQL. > 2018-08-28 18:32:12,082 [main] ERROR - > org.apache.calcite.sql.validate.SqlValidatorException: Object '_SUGGEST_' > not found within 'SALES' > 2) Travis build logs are huge, and it is hard to analyze failures. I ignore > "SqlValidatorException" in 100% of the cases, however it does take > noticeable time to load and scroll. > > Vladimir
