That'll be something for me to look into. That said, I'll throw out a pro-CM argument to see what people think.
Maybe I'm odd, but I keep CM open quite often when I'm working because it gives a good overall view of my data object layer. A concise presentation. When we push more things to code and other configuration files, it becomes more of a mental burden, at least for me, to bounce between lots of different and often bloated sources to track things down. I understand the desire to keep CM from becoming too bloated, but I also think CM provides a lot of value, too. Thanks, mrg On Wed, Jul 19, 2017 at 10:46 AM, Nikita Timofeev <[email protected] > wrote: > Hi Michael, > > Yes I have some new code for extension mechanics in project's XML, it > can store and load arbitrary data along with model and do it in such > way that it can be totally disabled at runtime. > It's used as a proof of concept to store comments and reverse > engineering config. > > But in your case it's really better to create new JdbcLogging > implementation that can skip some attributes defined by pluggable > strategy as suggested by Andrus. > > On Wed, Jul 19, 2017 at 3:49 PM, Michael Gentry <[email protected]> > wrote: > > I'll look forward to seeing what is introduced. Ultimately, there aren't > > that many sensitive fields in an application and a pluggable module to > > obscure those fields would likely be fine. > > > > > > On Wed, Jul 19, 2017 at 8:41 AM, Andrus Adamchik <[email protected] > > > > wrote: > > > >> 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 <[email protected]> > 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 > >> > >> > > > > -- > Best regards, > Nikita Timofeev >
