If we are talking about plugins, we should not forget that we'll need to support the current Modeler for a long time (very likely at least all the way till 4.1 final), as the new Modeler is a huge effort that should not block other development. I think the most promising vector is building a common Bootique-based plugin platform that can run both new and old modelers (as two separate apps).
Andrus > On Jul 20, 2017, at 3:08 PM, Michael Gentry <[email protected]> wrote: > > 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 <[email protected]> > 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 <[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 >>
