Best way to have everything needed in the Modeler is to support plugins :) Though it won't be an easy task to properly create plugin model (at least in current Modeler)
On Thu, Jul 20, 2017 at 2:06 PM, Michael Gentry <[email protected]> wrote: > 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 >> -- Best regards, Nikita Timofeev
