Uploaded image for project: 'Derby'
  1. Derby
  2. DERBY-2389

DOCS - Move Derby system and properties info from Tuning Guide into Reference Manual

Details

    • Improvement
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 10.4.2.0
    • 10.5.1.1
    • Documentation
    • 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

        1. DERBY-2389-adminguide.diff
          6 kB
          Camilla Haase
        2. DERBY-2389-adminguide.stat
          0.1 kB
          Camilla Haase
        3. DERBY-2389-adminguide.zip
          8 kB
          Camilla Haase
        4. DERBY-2389-devguide.diff
          24 kB
          Camilla Haase
        5. DERBY-2389-devguide.stat
          0.6 kB
          Camilla Haase
        6. DERBY-2389-devguide.zip
          38 kB
          Camilla Haase
        7. DERBY-2389-getstart.diff
          0.7 kB
          Camilla Haase
        8. DERBY-2389-getstart.stat
          0.0 kB
          Camilla Haase
        9. DERBY-2389-getstart.zip
          3 kB
          Camilla Haase
        10. DERBY-2389-phase2.diff
          111 kB
          Camilla Haase
        11. DERBY-2389-phase2.stat
          2 kB
          Camilla Haase
        12. DERBY-2389-phase2.zip
          64 kB
          Camilla Haase
        13. DERBY-2389-phase3.diff
          17 kB
          Camilla Haase
        14. DERBY-2389-phase3.stat
          0.5 kB
          Camilla Haase
        15. DERBY-2389-phase3.zip
          23 kB
          Camilla Haase
        16. DERBY-2389-phase3-2.diff
          17 kB
          Camilla Haase
        17. DERBY-2389-phase3-2.stat
          0.5 kB
          Camilla Haase
        18. DERBY-2389-phase3-2.zip
          23 kB
          Camilla Haase
        19. DERBY-2389-ref.diff
          174 kB
          Camilla Haase
        20. DERBY-2389-ref.stat
          2 kB
          Camilla Haase
        21. DERBY-2389-ref.zip
          151 kB
          Camilla Haase
        22. DERBY-2389-ref2.zip
          246 kB
          Camilla Haase
        23. DERBY-2389-tuning.diff
          160 kB
          Camilla Haase
        24. DERBY-2389-tuning.stat
          2 kB
          Camilla Haase
        25. DERBY-2389-tuning.zip
          74 kB
          Camilla Haase
        26. derbydev.pdf
          799 kB
          Camilla Haase
        27. tuningderby.pdf
          308 kB
          Camilla Haase

        Issue Links

          Activity

            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

            kmarsden Katherine Marsden added a comment - 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
            scotsmatrix Laura Stewart added a comment -

            Thanks Kathey, that's a really good suggestion

            scotsmatrix Laura Stewart added a comment - Thanks Kathey, that's a really good suggestion
            chaase3 Camilla Haase added a comment -

            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.

            chaase3 Camilla Haase added a comment - 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.
            chaase3 Camilla Haase added a comment -

            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.

            chaase3 Camilla Haase added a comment - 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...

            knutanders Knut Anders Hatlen added a comment - 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...
            chaase3 Camilla Haase added a comment -

            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.

            chaase3 Camilla Haase added a comment - 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.
            chaase3 Camilla Haase added a comment -

            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.

            chaase3 Camilla Haase added a comment - 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.
            chaase3 Camilla Haase added a comment -

            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.

            chaase3 Camilla Haase added a comment - 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.
            chaase3 Camilla Haase added a comment -

            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.

            chaase3 Camilla Haase added a comment - 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.
            chaase3 Camilla Haase added a comment -

            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.

            chaase3 Camilla Haase added a comment - 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.
            chaase3 Camilla Haase added a comment -

            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.

            chaase3 Camilla Haase added a comment - 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.
            chaase3 Camilla Haase added a comment -

            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.

            chaase3 Camilla Haase added a comment - 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.
            chaase3 Camilla Haase added a comment -

            I plan to commit these patches Friday 11/7 if I don't hear of any problems.

            chaase3 Camilla Haase added a comment - I plan to commit these patches Friday 11/7 if I don't hear of any problems.
            dagw Dag H. Wanvik added a comment -

            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?

            dagw Dag H. Wanvik added a comment - 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?
            dagw Dag H. Wanvik added a comment -

            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?

            dagw Dag H. Wanvik added a comment - 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?
            chaase3 Camilla Haase added a comment -

            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?

            chaase3 Camilla Haase added a comment - 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?
            chaase3 Camilla Haase added a comment -

            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.

            chaase3 Camilla Haase added a comment - 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.
            dagw Dag H. Wanvik added a comment -

            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.

            dagw Dag H. Wanvik added a comment - 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.
            chaase3 Camilla Haase added a comment -

            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.

            chaase3 Camilla Haase added a comment - 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.
            chaase3 Camilla Haase added a comment -

            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.

            chaase3 Camilla Haase added a comment - 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.
            chaase3 Camilla Haase added a comment -

            Patches have been committed. More may follow.

            chaase3 Camilla Haase added a comment - Patches have been committed. More may follow.
            chaase3 Camilla Haase added a comment -

            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?

            chaase3 Camilla Haase added a comment - 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.

            fuzzylogic Samuel Andrew McIntyre added a comment - 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.
            chaase3 Camilla Haase added a comment -

            Thanks very much, Andrew! Yes, everything looks fine now.

            chaase3 Camilla Haase added a comment - Thanks very much, Andrew! Yes, everything looks fine now.
            chaase3 Camilla Haase added a comment -

            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.)

            chaase3 Camilla Haase added a comment - 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.)
            chaase3 Camilla Haase added a comment -

            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.

            chaase3 Camilla Haase added a comment - 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?

            knutanders Knut Anders Hatlen added a comment - 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.

            knutanders Knut Anders Hatlen added a comment - 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.

            bryanpendleton Bryan Pendleton added a comment - Knut's suggestion to remove the sentence about conglomerate properties seems fine to me.
            chaase3 Camilla Haase added a comment -

            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.

            chaase3 Camilla Haase added a comment - 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.
            chaase3 Camilla Haase added a comment -

            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.

            chaase3 Camilla Haase added a comment - 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.
            chaase3 Camilla Haase added a comment -

            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

            chaase3 Camilla Haase added a comment - 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
            chaase3 Camilla Haase added a comment -

            Attaching PDFs for the Developer's Guide and Tuning Guide so that the structure changes are visible.

            chaase3 Camilla Haase added a comment - Attaching PDFs for the Developer's Guide and Tuning Guide so that the structure changes are visible.
            chaase3 Camilla Haase added a comment - - edited

            I will wait for a review after all, since this is a fair-sized change.

            chaase3 Camilla Haase added a comment - - edited I will wait for a review after all, since this is a fair-sized change.
            dagw Dag H. Wanvik added a comment -

            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")

            dagw Dag H. Wanvik added a comment - 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")
            chaase3 Camilla Haase added a comment -

            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.

            chaase3 Camilla Haase added a comment - 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.
            chaase3 Camilla Haase added a comment -

            Committed patch DERBY-2389-phase2.diff to documentation trunk at revision 745679.

            There's still some more to do; another patch will be forthcoming.

            chaase3 Camilla Haase added a comment - Committed patch DERBY-2389 -phase2.diff to documentation trunk at revision 745679. There's still some more to do; another patch will be forthcoming.
            chaase3 Camilla Haase added a comment -

            Turning off flag until a new patch is ready.

            chaase3 Camilla Haase added a comment - Turning off flag until a new patch is ready.
            chaase3 Camilla Haase added a comment -

            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.

            chaase3 Camilla Haase added a comment - 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 .
            chaase3 Camilla Haase added a comment -

            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

            chaase3 Camilla Haase added a comment - 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
            dagw Dag H. Wanvik added a comment -

            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.

            dagw Dag H. Wanvik added a comment - 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.
            chaase3 Camilla Haase added a comment -

            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

            chaase3 Camilla Haase added a comment - 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
            chaase3 Camilla Haase added a comment -

            Committed DERBY-2389-phase3-2.diff to trunk at revision 756574.

            Merged to 10.5 branch at revision 756616.

            chaase3 Camilla Haase added a comment - Committed DERBY-2389 -phase3-2.diff to trunk at revision 756574. Merged to 10.5 branch at revision 756616.
            chaase3 Camilla Haase added a comment -

            Closing issue, since changes appear in Latest Alpha Manuals.

            chaase3 Camilla Haase added a comment - Closing issue, since changes appear in Latest Alpha Manuals.

            People

              chaase3 Camilla Haase
              scotsmatrix Laura Stewart
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: