Ivan, I've been talking with different users from different industries and some of them(definitely not all of them) consider schema sensitive information. As a framework, that can be used by different types of users, we should cover this use case too. The solution, suggested by Ilya sounds very reasonable here - not all the users have so strict restrictions, but still, some of them have.
Best Regards, Evgenii пн, 5 апр. 2021 г. в 04:07, Ivan Daschinsky <ivanda...@gmail.com>: > Ilya, great idea, but I suppose that third option is a little bit paranoid. > But nevertheless, let it be, it's quite simple to implement it. > > пн, 5 апр. 2021 г. в 14:04, Ilya Kasnacheev <ilya.kasnach...@gmail.com>: > > > Hello! > > > > I have two ideas here: > > > > - Let's have more than a single level of sensitive information > withholding. > > Currently it is on/off, but I think we may need three levels: "print > all", > > "print structure but not content", "print none". > > By structure I mean table/column/field names and data types. So we can > > print SQL statements in their EXPLAIN form to log, but do not print any > > query arguments or values, substituting them with '?'. We can also print > > class and field names in various places. > > - If we have a default different from "print all", we should add a > > developer warning about it, such as > > [WARN ] Sensitive information will not be written to log by default. > > Consider *doing things* to enable developer mode. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > пн, 5 апр. 2021 г. в 13:45, Taras Ledkov <tled...@gridgain.com>: > > > > > Hi, > > > > > > I work on ticket IGNITE-14441 [1] to hide sensitive information at the > > > log messages produced by SQL. > > > There are negative comments for the patch. > > > > > > I guess we have to produce view to work with sensitive information and > > > make rules to define sensitive information. > > > > > > See on the usage of the GridToStringBuilder#includeSensitive. Class > > > names and field names now are considered sensitive. > > > My train of thought is this: SQL query and query plan contain table > name > > > (similar to class name) and field name. > > > So, the query and plan are completely sensitive. > > > > > > Lets define sensitive info and work with it for Ignite. > > > > > > Someone proposes introduce one more Ignite property for print SQL > > > sensitive info. > > > I think this leads to complication. > > > > > > Introduce levels of the sensitivity make sense but all similar > > > information must be handled with the same rules. > > > > > > Igniters, WDYT? > > > > > > [1]. https://issues.apache.org/jira/browse/IGNITE-14441 > > > > > > -- > > > Taras Ledkov > > > Mail-To: tled...@gridgain.com > > > > > > > > > > > -- > Sincerely yours, Ivan Daschinskiy >
