Thanks Scott,

This is indeed essentially it.

I'll get into details in a new thread. Notably about how to load data.

Jacques

Le 05/04/2018 à 10:39, Scott Gray a écrit :
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



Reply via email to