The topic of documenting Derby dash properties is being discussed on
DERBY-6305. These are the properties which occur in comments in Derby
queries, prefixed by the comment-initiating string "--derby-properties".
Some of these properties are documented. Some aren't. Some can be set by
users. Others can only be set by internal Derby-generated statements. A
document attached to DERBY-6305 lists these properties together with our
understanding of how they're used and whether they're described by our
user docs: DerbyDashProperties.html.
Probably our user docs shouldn't describe the internal properties. The
wiki can do that.
All of the customer-settable properties appear to be workarounds for
Derby performance bugs. It's unclear why some of these workarounds are
documented but others aren't. Possible reasons include:
1) We know how to characterize the performance issues addressed by the
documented workarounds. Conversely, we can't concisely describe why tech
support would recommend the undocumented workarounds.
2) We don't care if tech support forgets to file a performance bug after
recommending a documented workaround. Conversely, we want to make sure
that we hear about all performance bugs which would be addressed by
undocumented workarounds.
3) The undocumented, customer-settable Derby dash properties aren't
really workarounds. Instead, they are debug switches for use by derby-dev.
The documented Derby dash properties are:
joinOrder
index
constraint
joinStrategy
The undocumented Derby dash properties are:
useStatistics
hashIntialCapacity
hashLoadFactor
hashMaxCapacity
bulkFetch
Can anyone shed light on why some of the customer-settable Derby dash
properties are documented but the others aren't? This may involve code
or doc archaeology because some of the workarounds had their own
Cloudscape-specific syntax; that syntax was deprecated when Derby was
open-sourced and the workarounds were relegated to --derby-properties
comments.
Thanks,
-Rick
