My understanding is that Jacques is essentially proposing that: - Properties should either exist in the db or in files but not both - System configuration properties should go in files (I assume everything that isn't applicable to multi-tenanting) - Everything else should go to the db
If properties are only expected to exist in one of the two places, then the fallback behavior discussion becomes obsolete. Hope that helps. Jacques, sorry if I've misunderstood anything, please feel free to clarify. Regards Scott On 5 April 2018 at 07:26, Taher Alkhateeb <slidingfilame...@gmail.com> wrote: > There is no need to copy paste! I already read the jira and expressed my > confusion which is still the case. Your text is long and talks about many > things and does not provide a concrete proposal or a patch. > > What do you want to do? Rename system properties? Move properties? What are > they? Create tenant readers? Do further analysis? What is the proposal? And > why is the design discussion in a JIRA and not here? > > On Thu, Apr 5, 2018, 9:34 AM Jacques Le Roux <jacques.le.r...@les7arts.com > > > wrote: > > > OK, here is a copy of my comment in OFBIZ-7112 > > > > It's a long time now we have the SystemProperty entity. It was a good > > idea, that we spoke about <https://markmail.org/message/gdcefnghjtezyn4b > > > > even > > <https://markmail.org/message/gdcefnghjtezyn4b> longer ago < > > https://markmail.org/message/gdcefnghjtezyn4b> before it was implemented > > <http://svn.apache.org/viewvc?view=revision&revision=1238998>. I believe > > it's a good idea but there are 2 flaws in the current implementation. > > > > When we discussed about it before the implementation, it was clear that > > only business (ie not system) properties should be concerned > > <http://example.com/>. To be clear, for me the system properties are the > > properties in files at > > framework/start/src/main/java/org/apache/ofbiz/base/start and some other > > files like freemarkerTransforms.properties, fop.properties, > > catalina.properties, debug.properties, owasp.properties, > > security.properties, requestHandler.properties, url.properties and maybe > > some others I missed > > > > 1. So the 1st flaw was to name this entity SystemProperty. It should > have > > been named BusinessProperty. We could consider rename it, but that's > minor > > in comparison with the second flaw > > 2. The second flaw is that we kept the business properties files. To > > avoid duplication and confusion all the business properties should be in > the > > database and a specific UI should be created to easier handled them. > > > > We should also remember that when the idea was 1st expressed and > discussed > > there were no tenants in OFBiz (introduced in 2010). With now tenants, > > having business properties in data base is necessary and (almost?) all > > business properties should be shareable by tenants (to be checked). > > > > That's why I suggested to Deprecate properties in favour of > > SystemProperties <https://markmail.org/message/md6fuoouan377c6w>. I also > > suggested to have > > specific multitenant and multitenant-initial readers < > > https://markmail.org/message/opldepaevls3y3ob> for business properties > to > > separate those from > > other data. One thing I did not check yet is if the data I then called > > "only for tenants" are the business properties; and those which are not > are > > system properties. A deeper analysis is required but the idea seems to > fit. > > > > > > ------------------------------------------------------------ > ------------------------------------------------------------ > ------------------------------ > > > > TL;DR: We will not resolve the SystemProperties issues w/o no longer > using > > properties files but for the system properties. Of course then renaming > the > > SystemProperty entity to BusinessProperty is necessary. Having a specific > > UI for DB access for these properties is also necessary. I foresee the > > webtools as the best place for this UI. It should be accessible by > tenants. > > > > And to finish the reason why I want to keep Wai's work, is sometimes you > > need to annul a property. In this case the best way to do it in DB is how > > Wai > > implemented it, so it should not be removed. Rather the duplicated > > properties in files should be removed and replaced by properties in DB > only. > > > > Jacques > > > > > > Le 05/04/2018 à 07:42, Scott Gray a écrit : > > > If there's an ongoing discussion on the dev list then I don't think > it's > > a > > > good idea to try to move it to jira until there's some consensus on the > > > path forward. > > > > > > Regards > > > Scott > > > > > > On 4 April 2018 at 10:14, Taher Alkhateeb <slidingfilame...@gmail.com> > > > wrote: > > > > > >> I am a little lost in this JIRA and cannot follow the discussion. Can > > >> you please point to what you want to review with others exactly? > > >> > > >> On Wed, Apr 4, 2018 at 9:46 AM, Jacques Le Roux > > >> <jacques.le.r...@les7arts.com> wrote: > > >>> Le 03/04/2018 à 09:16, Jacques Le Roux a écrit : > > >>>> I suggest to continue the discussion at > > >>>> https://issues.apache.org/jira/browse/OFBIZ-7112 where I have > > >> completed my > > >>>> proposition > > >>> Since there were some more comments after is al link to my comment > with > > >> my > > >>> completed my proposition https://s.apache.org/7uwl > > >>> > > >>> Jacques > > >>> > > > > >
