cryptoe edited a comment on pull request #11911: URL: https://github.com/apache/druid/pull/11911#issuecomment-967079150
IMHO We can change the messaging a bit. Rather than calling it an error, we can say "QueryDiagnosis". `We tried to change the query shape to an intermediate "Union/Join/......" query but could not due to "reason".` Also, I think for the first cut `setPlannerError` should append errors rather than overwrite the error. This way, we can show all the possible "error" paths to the end-user. This way we are safeguarding against leading the user down the incorrect diagnosis path. Consider the scenario where the user wrote a 1000 line SQL query :) . Debugging such a query with an incorrect error message may not be the most pleasant experience :) If we want to show the message as an error I echo Gian's thought: > But, is there a potential for bizarre errors that relate to rules or query types that were explored, but didn't work out, and appear like nonsense to the user? We'd want to make sure that every time `setPlanningError` is called, it's something so fundamental that the overall query can't be handled by a different planner path. The idea is that we want to avoid a situation where there are two paths A and B, and each has an error, and the error from A is reported but doesn't make sense to the user because it is sort of path-A-specific. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
