db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: Proposal: default property file
Date Thu, 19 Jul 2007 10:13:56 GMT
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
> SYSCS_SET_DATABASE_PROPERTY.
>
> 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.

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'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

Mime
View raw message