Hi Mike, While I totally support solving this problem, I am not keen on overloading the core model with extra properties. We had this discussion under few different subjects, but it really comes down to the fact that there can be an infinite number of meanings one can associate with their model attributes (e.g. cayenne-crypto treats certain attributes as encrypted; a serialization framework may treat certain attributes as transient, etc., etc.). We just can't support all these things in the core. So I suggest that we don't.
Instead we may design this as an extension that can work on top of the core model. Kind of like cayenne-crypto, that determines which columns need to be encrypted not from the DataMap, but using a pluggable strategy (column naming convention by default). Also in 4.1 we will have a much more flexible model extension mechanism, which Nikita is about to present. All those requests that we had over the years of adding model comments and other arbitrary metadata will likely be fulfilled soon. So it will be easier to write extensions like the one you propose. Andrus > On Jul 19, 2017, at 3:28 PM, Michael Gentry <blackn...@gmail.com> wrote: > > Right now, everything is logged. It would be useful to be able to > configure certain column values to not be logged, especially in a > production environment. The main use case for this would be PII > (Personally Identifiable Information -- passwords, birthdays, social > security numbers, etc). Arguably, that information should be > hashed/encrypted, but it is still not something you'd want leaked into a > log file. Whenever a value isn't to be logged, put "[skipped]" in the log > output. > > I think it should work something like this: > > DataMap: > > Add a "Sensitive Logging" checkbox. Perhaps right under the "Optimistic > Logging" checkbox. Default = ON. > > > DbEntity / Entity Tab: > > Add a "Sensitive Logging" checkbox (basically mirroring the ObjEntity > "Optimistic Logging" checkbox). Default = ON. > > > DbEntity / Attributes Tab: > > Add a "Sensitive Logging" checkbox column (beside PK and Mandatory). > Default = OFF. (OFF means log the value normally. ON means conditionally > log per behavior below). > > > Upgrading older models: > > Default DataMap and DbEntity to ON. Leave DbEntity attributes OFF. > > > Behavior: > > skipped = > DataMap.ON && > DbEntity.Entity.ON && > DbEntity.Entity.Attribute.ON && > Log.Level > DEBUG > > if skipped > log [skipped] > else > log value > > > In a production environment, log levels are typically > INFO/WARN/ERROR/FATAL, so factor that into the skipping equation. When > developing, log levels are typically DEBUG/TRACE, and in that case, log the > value. > > Also, given that all of the above can be changed at run-time, it allows > flexibility in a production environment to turn the sensitive logging > on/off through admin interfaces should the need arise. > > Thoughts? > > Thanks, > > mrg