On 11 Feb 2008, at 04:59, Daniel John Debrunner wrote:
2) A somewhat similar but different issue is that all the Stored
Format Ids of all objects, regardless of layer, module, etc., is
stored in org.apache.derby.iapi.services.io.StoredFormatIds. In
this case, it is probably better to externalize this information
and load it at system startup.
Not sure what you mean here, these are just constants so not sure
what it means to load it at system startup. One issue with
distributing information is ensuring that different modules do not
define identical values in the same space. That's really the
purpose of StoredFormatIds (and some similarly shared classes), to
ensure a single allocation for each value.
Hi Dan,
It seems to me that the current solution is trying to solve following
problems:
a) Store reference data in one place so that issues such as
duplication can be avoided.
b) Having reference data in one place also acts as documentation, in
the sense that it helps to check things, etc.
c) The use of constants is also good for performance, as no further
lookup is necessary.
I think that each of these objectives could be met by a solution that
stores the reference data in external files, and loads them at
startup. In logical terms, a potential solution would be as follows:
Let's assume that there is a component that has following
responsibilities:
Load a set of key/value pairs from externally defined files into a
hash table.
Provide access to the values by key.
Allows keys to be grouped by namespaces.
Let's also assume that the data load happens when this component is
initialized, i.e., using a static initializer.
Modules that need to have their own set of "constants", can
initialize them as follows:
static final String A_CONSTANT = Component.get("namespace", "my.key");
The advantage of this approach over the current approach is that:
a) It maintains all the objectives of the current approach. Data can
be stored in a shared location, and therefore, we can avoid problems
such as use of duplicate values.
b) It ensures efficient access by allowing modules to continue using
constants for such values.
c) It makes the system more modular, as each module references only
those constants that it defines itself - there is no need for a
shared interface that defines all constants.
I don't see any particular disadvantage in taking this approach.
Regards
Dibyendu
