Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
10.4.2.0
-
None
Description
From Derby User list:
On 2/21/07, Anders Morken <andersmo@stud.ntnu.no> wrote:
> Shooting from the hip here, but one thing that has occured to me a few
> times as I've browsed the docs to figure something out is that I
> intuitively expect Derby system and database properties (especially the
> non-performance-related) to be documented in the reference guide, not
> the tuning guide. =)
On 2/21/07, Oystein Grovlen - Sun Norway <Oystein.Grovlen@sun.com> wrote:
> I agree on this. I would have preferred that all "facts" where
> presented in the Reference Manual, and that the other manuals where more
> "pedagogical" presentations of the same material. Currently, it is not
> very intuitive to determine which manual has the information you are
> looking for.
Attachments
Attachments
- DERBY-2389-adminguide.diff
- 6 kB
- Camilla Haase
- DERBY-2389-adminguide.stat
- 0.1 kB
- Camilla Haase
- DERBY-2389-adminguide.zip
- 8 kB
- Camilla Haase
- DERBY-2389-devguide.diff
- 24 kB
- Camilla Haase
- DERBY-2389-devguide.stat
- 0.6 kB
- Camilla Haase
- DERBY-2389-devguide.zip
- 38 kB
- Camilla Haase
- DERBY-2389-getstart.diff
- 0.7 kB
- Camilla Haase
- DERBY-2389-getstart.stat
- 0.0 kB
- Camilla Haase
- DERBY-2389-getstart.zip
- 3 kB
- Camilla Haase
- DERBY-2389-phase2.diff
- 111 kB
- Camilla Haase
- DERBY-2389-phase2.stat
- 2 kB
- Camilla Haase
- DERBY-2389-phase2.zip
- 64 kB
- Camilla Haase
- DERBY-2389-phase3.diff
- 17 kB
- Camilla Haase
- DERBY-2389-phase3.stat
- 0.5 kB
- Camilla Haase
- DERBY-2389-phase3.zip
- 23 kB
- Camilla Haase
- DERBY-2389-phase3-2.diff
- 17 kB
- Camilla Haase
- DERBY-2389-phase3-2.stat
- 0.5 kB
- Camilla Haase
- DERBY-2389-phase3-2.zip
- 23 kB
- Camilla Haase
- DERBY-2389-ref.diff
- 174 kB
- Camilla Haase
- DERBY-2389-ref.stat
- 2 kB
- Camilla Haase
- DERBY-2389-ref.zip
- 151 kB
- Camilla Haase
- DERBY-2389-ref2.zip
- 246 kB
- Camilla Haase
- DERBY-2389-tuning.diff
- 160 kB
- Camilla Haase
- DERBY-2389-tuning.stat
- 2 kB
- Camilla Haase
- DERBY-2389-tuning.zip
- 74 kB
- Camilla Haase
- derbydev.pdf
- 799 kB
- Camilla Haase
- tuningderby.pdf
- 308 kB
- Camilla Haase
Issue Links
- is related to
-
DERBY-1412 Possible values for derby.storage.rowLocking Derby engine is not currently documented eventhough the property is
- Closed
- relates to
-
DERBY-484 Documentation for derby.database.classpath in developers guide is misleading
- Closed
Activity
I think it's time to get to work on this job.
Moving these topics to the Reference Manual would have some drawbacks: it might confuse readers who are used to going to the Tuning Guide for this information, and it would make the largest manual even bigger.
It would also be somewhat tedious and error-prone to move and rename the topics and to fix all the references to them in the Tuning Guide and other manuals. I'm happy to do it, though.
There are relatively few direct cross-references to the property topics in the Tuning Guide itself – only about 8 that are not from other property topics. There may actually be more opportunities for direct cross-references in the Reference Manual.
I've been working through these and have run into some technical questions on tuning guide topics.
http://db.apache.org/derby/docs/dev/tuning/rtunproper27529.html (derby.storage.initialPages): The topic does not say whether the property is dynamic or static. The table of properties (ctunproper22250.html) implies that it is static (there is no X for dynamic). However, this is the only property that applies only to conglomerates (not system or database). Is the static/dynamic distinction relevant?
http://db.apache.org/derby/docs/dev/tuning/rtunproper81359.html (derby.storage.pageCacheSize): There's a paragraph referring to an ancient JVM (1.1.7) and OS (Windows NT). Is it possible to update this (i.e. do we have a valid suggestion for current software) or should it just be removed?
http://db.apache.org/derby/docs/dev/tuning/ctunsetprop824451.html (Scope of properties, under "Working with Derby properties" at the beginning of the Tuning Guide) describes the conglomerate-specific scope in addition to system-wide and database-wide. http://db.apache.org/derby/docs/dev/tuning/ctunproper51399.html (Scope of Derby properties), in the reference section that's being moved to the Reference Manual, mentions only the system-wide and database-wide scopes. Should the conglomerate-specific scope be added to ctunproper51399.html?
I'll be very grateful for advice on these.
derby.storage.initialPages:
From the description, it sounds like it is a dynamic property. Whenever it is set, subsequent CREATE TABLE and CREATE INDEX statements should use it. That's also what seems to be the intention of the code.
However, when I tested it, the property didn't seem to get picked up. I tried to set it both with the SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY procedure and as a system property, but the tables I created were always initialized with one page only (even after a reboot). Don't know what I'm doing wrong...
Thanks for checking! I guess we still don't know the story, then.
I've discovered another issue, in a Developer's Guide topic that refers to a tuning property: http://db.apache.org/derby/docs/dev/devguide/cdevconcepts23810.html (Lock granularity). It says,
For information on turning off row-level locking, see "derby.storage.rowLocking" in Tuning Derby.
This property is not yet documented – DERBY-1412 was filed by Francois Orsini quite a while ago to fix this. So I am picking up that issue.
Attaching DERBY-2389-tuning.diff, DERBY-2389-tuning.stat, and DERBY-2389-tuning.zip, which contain the Tuning Derby changes for this patch. This patch removes the "Derby properties" section and its subsections from this manual and also fixes the cross-references to these sections of this manual to point to the Reference Manual instead.
The zip file contains the HTML book version of the revised manual as well as the 7 changed individual HTML files. The book version makes it clear that the properties section is gone.
Attaching DERBY-2389-ref.diff, DERBY-2389-ref.stat, and DERBY-2389-ref.zip, containing the Reference Manual changes for this issue. This patch adds the "Derby properties" section and subsections to the Reference Manual and fixes cross-references in other files to point here. I also added a small section on dynamic and static properties with some of the information from Tuning Derby that is likely to be most useful to readers of this manual.
This zip file contains only the changed and added files. I'll attach another that shows the new structure.
Attaching DERBY-2389-ref2.zip, containing the HTML Book version of the modified Reference Manual, to show the structural change with the new Derby properties section.
Attaching DERBY-2389-adminguide.diff, DERBY-2389-adminguide.stat, and DERBY-2389-adminguide.zip. Three files that used to point to Tuning Derby now point to the Reference Manual.
Attaching DERBY-2389-devguide.diff, DERBY-2389-devguide.stat, and DERBY-2389-devguide.zip. 16 files that used to point to Tuning Derby now point to the Reference Manual.
In some cases I have also made some formatting fixes for consistency within and between topics, in addition to the cross-reference changes.
Attaching DERBY-2389-getstart.diff, DERBY-2389-getstart.stat, and DERBY-2389-getstart.zip, containing a small change to the topic that describes the contents of the manuals.
No changes need to be made to the tools guide, so this is the last patch.
I plan to commit these patches Friday 11/7 if I don't hear of any problems.
Thanks for this improvement, Kim!
I notice this sentence in the refman's introduction to the properties:
>To determine the result of this action, recall that the search order for properties is as follows (as stated in >"Precedence of properties" in Tuning Derby)
Is the "Presedence of properties" still explained in the Tuning guide (if so why?) or is this link wrong now?
I see it is still in Tuning, I guess what I am suggesting is that the explanation of properties (semanics), should be in the reference manual, only particular usage, as it pertains to tuning, should be in the tuning guide. Thoughts?
I'm glad you noticed this, Dag, because I was wondering about my solution to this problem.
There is a six-page section called "Working with Derby properties" that is mainly conceptual and task-oriented, rather than reference. I didn't want to move it all into the Reference Manual because the Reference Manual is not really for conceptual and how-to information – I copied over the most basic information (scope) that's needed to understand the "Derby properties" topic and left the rest in the Tuning Guide. But I'm not sure it belongs in the Tuning Guide either. It might make more sense to put it in part 2 of the Admin Guide, along with the other tasks there.
What do you think?
I'm planning to commit these patches as is in the next day or two unless I hear otherwise. If any further reorganizations are needed, they can be done afterwards.
I think the essential semantics should be explained in the reference manual. The precedence information
is part of that, in my view. Usually, the developer's guide carries the conceptual information. If it task admin task related, the admin guide is good. +1 to commit and refine later.
Thanks, Dag, I will do the commit (but not resolve the issue) and then see what more needs to be done.
The essential precedence information is now in the "Derby properties" topic (crefproper22250.html). Do you think more is needed?
(BTW, having two topics named "Derby properties" is not good – I should rename one of them.)
That's a good point about the Dev Guide. I'll have to consider whether the properties topics have more to do with developer tasks or admin tasks.
Committed patch DERBY-2389-ref.diff to documentation trunk at revision 713746.
Committed patch DERBY-2389-tuning.diff to documentation trunk at revision 713812.
Committed patch DERBY-2389-devguide.diff to documentation trunk at revision 713814.
Committed patch DERBY-2389-adminguide.diff to documentation trunk at revision 713816.
Committed patch DERBY-2389-getstart.diff to documentation trunk at revision 713819.
A little more cleanup remains to be done.
Since I committed these patches, the Latest Alpha Manuals generation on http://db.apache.org/derby/manuals/index.html seems to have fallen over again (after working very nicely for a month or so). Can it be revived?
Hi Kim, I'm not sure what was preventing the copy from happening, but I kicked the copy of the docs off by hand and it appears to be working. The docs should be updated in an hour or so.
I've been thinking about the "Working with Derby properties" topics in Tuning Derby and whether they still belong there.
There are NO cross-references to these topics elsewhere in Tuning Derby, which suggests that the content really doesn't have much to do with tuning.
There is one such cross-reference in the Admin Guide.
There are six in the Developer's Guide, which suggests that the content might belong there, as Dag was thinking. Three are in the "Derby and Security" topics and the other three are in "JDBC applications and Derby basics."
The question then arises where in the Developer's Guide to put the topics. Here are some possibilities.
- as a third subsection of "JDBC applications and Derby basics," after "Derby embedded basics"
- as another subsection of "Controlling Derby application behavior", which contains some other "Working with ..." subsections
- as another top-level topic, maybe after "JDBC applications and Derby basics"
I'm leaning toward the first – would anyone like to weigh in on this?
(BTW, that section "After installing" should probably be nearer to the beginning of the book, shouldn't it? Maybe right after the Upgrades section? That's a separate issue, though.)
One of the topics to be moved from the Tuning Guide to the Developer's Guide has a sentence that I can't decipher. The topic http://db.apache.org/derby/docs/dev/tuning/ctunsetprop824451.html (Scope of properties), has the following under the "conglomerate-specific" bullet:
"Beginning with Derby properties relating to conglomerates cannot be specified as part of the create-statement for the object."
Looks like there was supposed to be a version number after "Derby", but the sentence has been like this since 10.0. Would it be correct to say just the following?
"Properties relating to conglomerates cannot be specified as part of the create-statement for the object."
Also, what is meant by "create-statement"? I don't know of any way to set properties in either a CREATE statement or a Connection.createStatement method call.
My guess is that it means to say: "Beginning with Derby, in contrast to Cloudscape, properties relating to conglomerates cannot ...". Cloudscape probably allowed you to specify conglomerate properties in CREATE TABLE/INDEX.
Do the manuals talk about other non-standard constructs that were supported by Cloudscape but not by Derby? If not, should we simply remove that sentence?
This page documents the CREATE TABLE syntax in Cloudscape 3.6.1:
http://www.dwfa.ca/Library/Java/Cloudscape/v3.6.1/doc/html/coredocs/sqlj16.htm
It says:
> You can specify storage properties such as page size for a table
> with a PROPERTIES clause. See PROPERTIES clause.
Knut's suggestion to remove the sentence about conglomerate properties seems fine to me.
Thanks for all your help, Knut Anders and Bryan. I think it is safe to remove the "conglomerate-specific" bullet item from this topic, since there is no way to set properties specific to a conglomerate, and the workaround – to set a database property that applies to conglomerates created subsequently – is described in the previous bullet item about database-wide scope.
Here's another little puzzle. I'm trying to update the Reference Manual mentions of the Tuning Guide so that they point to the correct places for the material that's moving to the Developer's Guide. I came across one reference that has nothing to do with the properties topics, but that seems to be incorrect. The topic on the FOR UPDATE clause, http://db.apache.org/derby/docs/dev/ref/rrefsqlj31783.html, says,
"The optimizer is able to use an index even if the column in the index is being updated. For more information about how indexes affect cursors, see Tuning Derby."
Well, cursors are mentioned precisely once in Tuning Derby (check the one-page version, http://db.apache.org/derby/docs/dev/tuning/tuning-single.html, to make sure), and there's nothing there that seems relevant to indexes. This sentence has been in the docs forever, but it may refer to some material that was in the Cloudscape docs but was removed for Derby.
Can anyone find what the sentence might be referring to? If not, I'm inclined to remove it.
Attaching DERBY-2389-phase2.diff, DERBY-2389-phase2.stat, and DERBY-2389-phase2.zip. This patch moves the "Working with Derby properties" topics from the Tuning Guide to the Developer's Guide and modifies the references to these topics.
The changes affect one file each in the Admin Guide and Getting Started, a few files in the Reference Manual, and numerous files in the Tuning and Developer's Guides.
A few miscellaneous changes in addition:
- Changed a topic title in the Reference Manual so there are no longer two topics with the name "Derby properties".
- Moved the "After installing" topics in the Developer's Guide to the beginning of the book and updated the "How this guide is organized" topic to reflect the current contents of the book.
- Moved the two subtopics of "Changing the system-wide properties programmatically", which were short and deeply nested, into their parent topic.
The following files change:
M src/adminguide/cadminlockvti83889.dita
M src/getstart/rgsdocs17307.dita
M src/ref/rrefproper24390.dita
M src/ref/rrefproper32213.dita
M src/ref/rrefsqlj31783.dita
M src/ref/crefproper51399.dita
M src/ref/crefproper22250.dita
M src/ref/refderby.ditamap
M src/devguide/cdevconcepts22300.dita
A src/devguide/cdevsetprop824500.dita
A src/devguide/cdevsetprop24222.dita
M src/devguide/derbydev.ditamap
A src/devguide/cdevsetprop44147.dita
M src/devguide/cdevdgpref23947.dita
A src/devguide/cdevsetprop824533.dita
A src/devguide/cdevsetprop23308.dita
M src/devguide/tdevcsecure81850.dita
M src/devguide/cdevdvlp39943.dita
M src/devguide/cdevdvlp846110.dita
M src/devguide/cdevcsecure864692.dita
A src/devguide/cdevsetprop824615.dita
A src/devguide/cdevsetprop11561.dita
A src/devguide/cdevsetprop32443.dita
M src/devguide/cdevdvlp13018.dita
A src/devguide/cdevsetprop13074.dita
A src/devguide/cdevsetprop11108.dita
A src/devguide/cdevsetprop16827.dita
A src/devguide/cdevsetprop824983.dita
A src/devguide/cdevsetprop24843.dita
A src/devguide/cdevsetprop34818.dita
A src/devguide/cdevsetprop824451.dita
A src/devguide/cdevsetprop12821.dita
D src/tuning/ctunsetprop824451.dita
D src/tuning/ctunsetprop12821.dita
D src/tuning/ctunsetprop824615.dita
M src/tuning/tuningderby.ditamap
D src/tuning/ctunsetprop11561.dita
D src/tuning/ctunsetprop824500.dita
D src/tuning/ctunsetprop24222.dita
D src/tuning/ctunsetprop32443.dita
D src/tuning/ctunsetprop44147.dita
D src/tuning/ctunsetprop824533.dita
M src/tuning/ctunpropref23947.dita
D src/tuning/ctunsetprop13074.dita
D src/tuning/ctunsetprop23308.dita
D src/tuning/ctunsetprop38343.dita
D src/tuning/ctunsetprop1003847.dita
M src/tuning/ctunpropref11181.dita
D src/tuning/ctunsetprop11108.dita
D src/tuning/ctunsetprop16827.dita
D src/tuning/ctunsetprop824983.dita
D src/tuning/ctunsetprop24843.dita
D src/tuning/ctunsetprop34818.dita
Attaching PDFs for the Developer's Guide and Tuning Guide so that the structure changes are visible.
I will wait for a review after all, since this is a fair-sized change.
Really good to see this clean-up, Kim! Sorry for the late review.
I am ok with committing now, and fixing up the remaining items in a
follow-up patch if that seems better than respinning this large patch.
I applied the patch and it built cleanly; I scanned the text for
references to Tuning Derby and found only one outdated link, see
below.
- Dev guide (I reviewed this material by reading the pdf-version's new
section on Working with properties in its entirety; so some comments
below relate to issues with the original material from the Tuning
guide, not to changes introduced by moving the material. Feel free
to ignore such comments, fix them now, or make separate JIRAs for
them as you see fit
- "Derby and Security"
"Configuring security in a client/server environment"
"This procedure requires a system with multiple databases and some administrative
resources.
1. Configure security features as system properties. See Tuning Derby."
***************
Outdated link.
- working with properties
- properties overview
The sentence "When you change these properties, they affect any
tables or indexes created after this change" occurs twice; under
both system and database scope. Above, the term conglomerate is
introduced and defined. Suggest use it in this sentence (why else
define it?)
Also I am a bit wary of the sentence itself, I would invert its
structure to make clearer we are only talking about what happens
for such properties in relation to conglomerates:
"When you change these properties, they affect any
conglomerates created after this change"
Suggest:
"For properties that affect conglomerates, changing the value of
such properties only affect conglomerates created after the
change. Conglomerates created earlier are unaffected".
- Setting Derby properties:
- In the reference to "IBM Application Developer Kits": Make this
generic (not?) or include reference to Sun's Java as well..
- "not as properties of the type discussed in this book"
"book" is misleading now; use section instead?
- «For more information, see "java.sql.DriverManager.getConnection
method" and "Setting attributes for the database connection URL"
in the Derby Reference Manual.»
After moving, maybe it is now reasonable here to refer directly with
a link to the proper section in the dev guide as well?
- "There should be one derby.properties file per system, not per
database."
Suggest:
"There can be only one derby.properties file per system, not one
per database."
- "Database-wide properties, which affect a single database, are
stored within the database itself. This allows different
databases within a single Derby system to have different
properties and ensures that the properties are correctly set
when a database is moved away from its original system or
copied."
suggest:
"... and ensures that the properties are correctly retained
when a database is moved away..."
- "Note: You should use database-wide properties wherever possible
for ease of deployment."
I think this point should be explained more at the outset of the
"working with properties section" to give the user an idea up
front that system properties are practical at development time,
but database properties are preferrable at deployment time. I
think we (used to?) have such an explanation somewhere.. can't
find it right now...
- "If you specify an invalid value, Derby uses the default value for
the property."
So, if a subsequent SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY is
called, does it return the default or the non-valid value set?
The reference manual section doesn't explain this either:
http://db.apache.org/derby/docs/dev/ref/rrefsetdbpropproc.html
- Typo: "Client applications can set database-wide because
- "properties" missing
they are set via SQL statements."
- "Client applications can set dynamic system-wide properties in an
SQL statement, as shown in the example in Using a Properties
object within an application or statement."
This seems to refer to URL attribute setting on the client side,
not dynamic system-wide properties? It also seems to contradict
the earlier statement in this section:
"In a client/server environment, you must set the system
properties for the server's system."
- Case study
- "java -Dderby.system.home=c:\system_directory MyApp"
and others should be marked as Windows-centric.
This example could use an extra blank line, IMHO:
java -Dderby.system.home=c:\system_directory
-Dderby.storage.pageSize=4096 MyApp
CREATE TABLE anothertable (a INT, b VARCHAR(10))
The rest of the changes i reviewed by looking at the diffs and the HTML pages.
- adminguide/cadminlockvti83889.html OK
- getstart/rgsdocs17307.html OK
- ref/crefproper22250.html OK
- ref/crefproper51399.html OK
- ref/rrefproper24390.html OK
- ref/rrefproper32213.html OK
- ref/rrefsqlj31783.html
The reference to Tuning guide here for cursors was removed I see.
I guess you could make it applicable by just rewording it a bit, e.g. as
"For more information about how indexes affect performance, see.."
but it's not essential here, so removing it is fine too.
- tuning/ctunpropref11181.html
"how to tune systems" " also contain tuning tips"
No need for both of the above? Seems confusing..
- tuning/ctunpropref23947.html OK
- devguide/cdevconcepts22300.html OK
Good new link here!
- devguide/cdevcsecure864692.html OK
- devguide/cdevdgpref23947.html
Good catches here; missing stuff!
- devguide/cdevdvlp13018.html OK
- devguide/cdevdvlp39943.html OK
- devguide/cdevdvlp846110.html
"Note: You should work with database-level properties wherever possible."
This statement should explained, I think, perhaps referring to a
general section explaining recommended usage of system level
("flexible at development time") vs. database level properties
("safest for deployment")
Thank you so much, Dag, for the very thorough review! I will figure out how many files are affected and decide what to do accordingly.
Committed patch DERBY-2389-phase2.diff to documentation trunk at revision 745679.
There's still some more to do; another patch will be forthcoming.
Dag, you asked, about http://db.apache.org/derby/docs/dev/devguide/cdevsetprop12821.html:
- "If you specify an invalid value, Derby uses the default value for
the property."
So, if a subsequent SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY is
called, does it return the default or the non-valid value set?
The reference manual section doesn't explain this either:
http://db.apache.org/derby/docs/dev/ref/rrefsetdbpropproc.html
A limited experiment (using derby.connection.requireAuthentication, derby.authentication.provider, and derby.storage.initialPages) suggests the following:
At the beginning, if a property is not set at all, SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY returns "null", but appears to use the default value. If you then set the property to an invalid value, SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY returns the invalid value, but appears to use the default value as before.
I should probably edit http://db.apache.org/derby/docs/dev/ref/rrefsetdbpropproc.html and probably http://db.apache.org/derby/docs/dev/ref/rrefgetdbpropfunc.html to mention this, as well as http://db.apache.org/derby/docs/dev/devguide/cdevsetprop12821.html.
Attaching DERBY-2389-phase3.diff, DERBY-2389-phase3.stat, and DERBY-2389-phase3.zip, incorporating the latest comments (I hope). The following files are changed:
M src/devguide/cdevdvlp846110.dita
M src/devguide/cdevsetprop11561.dita
M src/devguide/cdevsetprop32443.dita
M src/devguide/cdevsetprop13074.dita
M src/devguide/cdevsetprop24843.dita
M src/devguide/cdevsetprop824451.dita
M src/devguide/cdevsetprop12821.dita
M src/ref/rrefsetdbpropproc.dita
M src/ref/rrefgetdbpropfunc.dita
M src/ref/rrefsqlj31783.dita
M src/ref/crefproper51399.dita
M src/tuning/ctunpropref11181.dita
Thanks for the latest sets of fixes (phase3), Kim!
Some final comments; feel free to commit and close this issue now!
- cdevsetprop13074.dita
> There should be one derby.properties file per system, not one per database.
Suggest:
There is one one derby.properties ...
- cdevsetprop24843.dita
> Programmatically (as a command-line option to the JVM when starting
> the application or within application code)
This is misleading, since the application is normally the client side.
Suggest:
(as a command line option when starting the JVM that holds
the server or, if the server is started from with a program,
programmatically by the program which hosts the server)
- cdevsetprop824451.dita
> Database-wide properties are stored in the database and are simpler for deployment.
Suggest:
Database-wide properties are stored in the database and are simpler
for deployment, in the sense that they follow they
database. Database-wide properties are also recommended for security
reasons when Derby built-in authentication is used, cf ...
- cdevsetprop12821.dita
> You should use database-wide properties wherever possible for ease of deployment.
Suggest adding a final:
".. and security"
- crefproper51399.dita
> Note: Database-wide properties are stored in the database and are simpler for deployment.
Suggest:
Note: Database-wide properties are stored in the database and are
simpler and safer for deployment.
Thank you very much, Dag! I have made these changes and am attaching them as a patch, which I will commit:
DERBY-2389-phase3-2.diff
DERBY-2389-phase3-2.stat
DERBY-2389-phase3-2.zip
Committed DERBY-2389-phase3-2.diff to trunk at revision 756574.
Merged to 10.5 branch at revision 756616.
When this is done, it would be good to have a cross reference with the doc on the
SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY procedure at
http://db.apache.org/derby/docs/10.2/ref/rrefsetdbpropproc.html