You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ofbiz.apache.org by "Jacques Le Roux (Jira)" <ji...@apache.org> on 2022/08/30 09:08:00 UTC

[jira] [Comment Edited] (OFBIZ-7112) EntityUtilProperties

    [ https://issues.apache.org/jira/browse/OFBIZ-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16423553#comment-16423553 ] 

Jacques Le Roux edited comment on OFBIZ-7112 at 8/30/22 9:07 AM:
-----------------------------------------------------------------

Hi Aditya,

Please don't, and let me explain why.

It's a long time now we have the SystemProperty entity. It was a good idea, that [we spoke about 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 To be clear, for me the system properties are the properties in files at framework/start/src/main/resources/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 :)
 # 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
 # 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.


was (Author: jacques.le.roux):
Hi Aditya,

Please don't, and let me explain why.

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 :)
 # 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
 # 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.

> EntityUtilProperties
> --------------------
>
>                 Key: OFBIZ-7112
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-7112
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: ALL COMPONENTS
>    Affects Versions: Trunk, Upcoming Branch
>            Reporter: Wai
>            Assignee: Jacques Le Roux
>            Priority: Major
>         Attachments: OFBIZ-7112.patch, OFBIZ-7112.patch, OFBIZ-7112.patch, OFBIZ-7112.patch, OFBIZ-7112.patch
>
>
> Ofbiz reads properties from either a properties file or the entity:SystemProperty. The way it works previously is that ofbiz reads from the entity:SystemProperty first and if there is no value associated with the target propertyname, it would then locate the value from the relevant properties file.
> In other words, if there is a database entry for a property, the database entry should override the associated properties file.
> The issue is that if a database entry exist but the value is empty, it would look for a value from the properties file.  It should not do so.  If a database entry exists for the propertyname of interest, the value should be taken from the database even if it holds an empty value.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)