Yes, that would be nice. I've given it a little thought in the new modeler I've started, but only a little. Probably at least two extension points needed:
1) Completely separate window (the easiest). 2) Access to existing editors (much harder and more fragile if the UI layout changes). Perhaps I should give it some more thought and make the current editors themselves plugins... On Thu, Jul 20, 2017 at 7:57 AM, Nikita Timofeev <ntimof...@objectstyle.com> wrote: > 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 <blackn...@gmail.com> > 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 < > ntimof...@objectstyle.com > >> 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 <blackn...@gmail.com> > >> 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 < > and...@objectstyle.org > >> > > >> > 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 <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 > >> >> > >> >> > >> > >> > >> > >> -- > >> Best regards, > >> Nikita Timofeev > >> > > > > -- > Best regards, > Nikita Timofeev >
