db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Gunnar Borstad <oleg...@stud.ntnu.no>
Subject Re: Proposal: default property file
Date Fri, 20 Jul 2007 07:12:41 GMT
Siterer Knut Anders Hatlen <Knut.Hatlen@Sun.COM>:

> Ole Gunnar Borstad <olegunb@stud.ntnu.no> writes:
>> I am working on management and monitoring of Derby through JMX, and
>> viewing and modifying Derby properties has proven to be complicated.
>> The problem is that there is no interface to properties when they have
>> *default* values (this goes for both system- and database-wide
>> properties). PropertyUtil returns null-values for system-wide, and the
>> system procedure SYSCS_GET_DATABASE_PROPERTY returns null-values for
>> database-wide.
>> System properties are only accessible if set explicitly by the user
>> (code/command line or derby.properties). Database properties are only
>> accessible if set through the system procedure
>> What if we put all default property settings in a default property
>> file? Derby could read this file and load the default properties,
>> before it continues with derby.properties (if the user specified one)
>> and overwrites the previously read properties. Alternatively,
>> derby.properties could be built automatically with default properties
>> (including database-wide properties). The user could then make changes
>> to this file.
>> Currently, anyone who wishes to explore default properties have to
>> read Derby documentation. The proposed change gives a clean interface
>> to Derby properties, which easily enables management. A management
>> feature will query the properties in a uniform manner, default values
>> or not. I believe this would benefit the usability of Derby, and of
>> course make management and monitoring much easier.
> Sounds like a very good idea to me. When you talk about a default
> property file, are you thinking about (1) a file somewhere on the user's
> file system, (2) a file in the database directory, (3) a file inside
> derby.jar, or perhaps something else? I would say (3) sounds like the
> best option since that file could contain both database properties and
> system properties, and you would know that it's always there.

I agree (3) sounds like the best option.

> We could also take the idea one step further and create a file with
> meta-data about the properties, for instance a description, whether it's
> a database property or a system property, minimum value, maximum value
> and default value. This could be helpful information both for
> management/monitoring and perhaps some time for automatically generated
> documentation.

I like this idea, it's pretty much what Derby is lacking wrt.
properties; A clean and comprehensible interface. I don't know if this
has to be done the hardcore way with XML or something, or if we could
just do it with commenting. I think derby.properties uses # for
comments. Keeping it simple is a must I guess?

> I'm not sure whether automatically building derby.properties with
> default properties would solve this problem (at least not alone) since
> the users may want to strip down the file by removing some of the
> default settings. Also, there might perhaps be properties that we don't
> want to encourage the users to change, but still should have a default
> value. But from a usability point of view, I think it would be helpful
> to create a default derby.properties with (commented out) examples for
> properties that many users may want to change/add.
> --
> Knut Anders

Good, then we ruled that out.

- Ole Gunnar

View raw message