stoty commented on pull request #1210: URL: https://github.com/apache/phoenix/pull/1210#issuecomment-829785191
Being able to specify a single logging implementation wouldn't get us far. To support even the current use case, we'd need to be able to specify the logging class and log level for at least for the queries and the DML/DDL statements separately. The implementation detail of having a separate logger class is not exposed in the configuration. Once we figure out how to have more generic logging configuration, the current behaviour can be folded into that. I think that in more generic configuration we should have single logger and feed all logging events to that. That intelligent logger would then (pre) compute the aforementioned big matrix of what should go into the log based on the query type and what we specified in the new-style configuration, and add/ignore the events based on that. I agree that we WOULD have to add some backwards compatibility code to map the current settings to the future more flexible method, which is not ideal, but we'll have to do the same for the existing query logger configuration setting anyway. I gave some thought about how to add redaction to the logging, but it seeems pretty daunting. You could probably flag fields and identify them at statement compilation time, but then you'd have to re-generate the logged query text from the redacted query plan. (And I'm not sure how UDFs would interfere with this) -- 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. For queries about this service, please contact Infrastructure at: [email protected]
