RFC: Properties Idea

[Adrian Crum]

Now that OFBiz supports XML properties files, I've started thinking about David's comment that
configuration settings and such should be kept in the database - and how to add that capability to
the UtilProperties class bag of tricks.

Just like the XML properties file idea, I'd like to make it transparent to the developer. I'm
thinking we would need only one entity, and a little more work on the UtilProperties class.

The entity would be something like:

ResourceProperties
------------------
ResourceName, id-long
PropertyKey, id-long
PropertyValue, very-long

So, if you called UtilProperties.getPropertyValue("MyResource", "MyProperty") the usual properties
files would be checked first, and if that failed, the ResourceProperties entity would be searched.
UtilProperties would keep the entity version of Properties objects in the same cache as regular
file-based Properties objects.

What do you think?

The only thing I haven't figured out is how to get a delegator instance. In the example above, there
are two String parameters - no delegator. I know I can call
GenericDelegator.getGenericDelegator(String delegatorName) but what delegator name do I use? Any
ideas on how that would/should work?

-Adrian

[David E Jones]

This is an interesting approach, but very different from what I had  
imagined and what has been discussed (though not in a lot of detail).

Rather than creating a generic structure I'd rather continue with the  
existing pattern of designing data model extensions according to the  
nature of the configuration option.

That approach is certainly more work, but ultimately more valuable and  
easier to use and maintain going forward. All options are basically  
listed out and can be restricted more using enums as needed, and  
structured relative to whatever makes sense like a product store or  
organization party or whatever.

This also helps clarify which options should or should not go in the  
database. IMO only the business level configuration options should go  
in the database and not the "technical", or perhaps better labeled  
"system", level ones. If it relates to something in the current data  
model, like payment settings for example, then it makes sense to  
create a structure for and put it in the database. That particular  
example would also allow us to get rid of some hackish things like  
specifying the properties file name in an entity field.

-David


On Dec 7, 2007, at 3:42 PM, Adrian Crum wrote:

> Now that OFBiz supports XML properties files, I've started thinking  
> about David's comment that configuration settings and such should be  
> kept in the database - and how to add that capability to the  
> UtilProperties class bag of tricks.
>
> Just like the XML properties file idea, I'd like to make it  
> transparent to the developer. I'm thinking we would need only one  
> entity, and a little more work on the UtilProperties class.
>
> The entity would be something like:
>
> ResourceProperties
> ------------------
> ResourceName, id-long
> PropertyKey, id-long
> PropertyValue, very-long
>
> So, if you called UtilProperties.getPropertyValue("MyResource",  
> "MyProperty") the usual properties files would be checked first, and  
> if that failed, the ResourceProperties entity would be searched.  
> UtilProperties would keep the entity version of Properties objects  
> in the same cache as regular file-based Properties objects.
>
> What do you think?
>
> The only thing I haven't figured out is how to get a delegator  
> instance. In the example above, there are two String parameters - no  
> delegator. I know I can call  
> GenericDelegator.getGenericDelegator(String delegatorName) but what  
> delegator name do I use? Any ideas on how that would/should work?
>
> -Adrian
>
>

[Adrian Crum]

David,

Thank you very much for your comments. I agree with the idea of data model extensions designed
around a particular configuration option.

I was thinking more along the lines of having some of the system-level configuration options stored
in an entity - so we could have a basic system configuration UI. Of course some things could be left
out - like the cache settings you mentioned previously.

I'll put the idea on the shelf for now.

-Adrian

David E Jones wrote:

>
> This is an interesting approach, but very different from what I had  
> imagined and what has been discussed (though not in a lot of detail).
>
> Rather than creating a generic structure I'd rather continue with the  
> existing pattern of designing data model extensions according to the  
> nature of the configuration option.
>
> That approach is certainly more work, but ultimately more valuable and  
> easier to use and maintain going forward. All options are basically  
> listed out and can be restricted more using enums as needed, and  
> structured relative to whatever makes sense like a product store or  
> organization party or whatever.
>
> This also helps clarify which options should or should not go in the  
> database. IMO only the business level configuration options should go  
> in the database and not the "technical", or perhaps better labeled  
> "system", level ones. If it relates to something in the current data  
> model, like payment settings for example, then it makes sense to  create
> a structure for and put it in the database. That particular  example
> would also allow us to get rid of some hackish things like  specifying
> the properties file name in an entity field.
>
> -David
>
>
> On Dec 7, 2007, at 3:42 PM, Adrian Crum wrote:
>
>> Now that OFBiz supports XML properties files, I've started thinking  
>> about David's comment that configuration settings and such should be  
>> kept in the database - and how to add that capability to the  
>> UtilProperties class bag of tricks.
>>
>> Just like the XML properties file idea, I'd like to make it  
>> transparent to the developer. I'm thinking we would need only one  
>> entity, and a little more work on the UtilProperties class.
>>
>> The entity would be something like:
>>
>> ResourceProperties
>> ------------------
>> ResourceName, id-long
>> PropertyKey, id-long
>> PropertyValue, very-long
>>
>> So, if you called UtilProperties.getPropertyValue("MyResource",  
>> "MyProperty") the usual properties files would be checked first, and  
>> if that failed, the ResourceProperties entity would be searched.  
>> UtilProperties would keep the entity version of Properties objects  in
>> the same cache as regular file-based Properties objects.
>>
>> What do you think?
>>
>> The only thing I haven't figured out is how to get a delegator  
>> instance. In the example above, there are two String parameters - no  
>> delegator. I know I can call  
>> GenericDelegator.getGenericDelegator(String delegatorName) but what  
>> delegator name do I use? Any ideas on how that would/should work?
>>
>> -Adrian
>>
>>
>

[David E Jones]

On Dec 11, 2007, at 8:56 AM, Adrian Crum wrote:

> I was thinking more along the lines of having some of the system-
> level configuration options stored in an entity - so we could have a  
> basic system configuration UI. Of course some things could be left  
> out - like the cache settings you mentioned previously.
>
> I'll put the idea on the shelf for now.

I'm pretty against having configuration like this in the database...  
it makes it really difficult to manage overall, largely because  
revision control is either not there, or done in the database separate  
from the code revision control, making deployments very error prone  
because you have to manually keep an eye on these settings in the  
database and make sure they are up to date.

If you have a config UI it makes it even more difficult to manage  
because if someone changes something in the UI and someone else  
writing code makes a corresponding configuration in the file system,  
when the data is reloaded you might end up with a change loss  
problem... and that's only one scenario.

-David