Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <820241.1145201310868.JavaMail.jira@brutus>
Date: Sun, 16 Apr 2006 15:28:30 +0000 (GMT+00:00)
From: "John H. Embretsen (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Closed: (DERBY-981) Errors in Tuning Guide's "Properties
 case study"
In-Reply-To: <1035718756.1139926929024.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/DERBY-981?page=all ]
     
John H. Embretsen closed DERBY-981:
-----------------------------------


Verified that the fix is present in the latest (alpha) Tuning Guide.

Closing the issue, thanks for committing!


> Errors in Tuning Guide's "Properties case study"
> ------------------------------------------------
>
>          Key: DERBY-981
>          URL: http://issues.apache.org/jira/browse/DERBY-981
>      Project: Derby
>         Type: Bug

>   Components: Documentation
>     Versions: 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.0.2.0, 10.2.0.0, 10.1.2.2, 10.1.2.1, 10.1.2.0, 10.1.1.2
>  Environment: All
>     Reporter: John H. Embretsen
>     Assignee: John H. Embretsen
>     Priority: Minor
>      Fix For: 10.2.0.0
>  Attachments: DERBY-981_v1.diff, DERBY-981_v1.stat, ctunsetprop32443_v1.html
>
> The tuning guide contains a "Properties case study", demonstrating precedence and persistence of derby properties; see http://db.apache.org/derby/docs/dev/tuning/ctunsetprop32443.html. There is at least one factual error and a couple of inaccurate details in this case study:
> 1) The value of the property derby.storage.pageSize that is being used in the last example should be 32768, not 8192:
> After the example statement 
> CREATE TABLE table4 (a INT, b VARCHAR(10))
> the case study states
> "Derby uses the persistent database-wide property of 8192 for this table, since the database-wide property set in the previous session is persistent and overrides the system-wide property set in the derby.properties file."
> In the previous session, however, the database-wide property derby.storage.pageSize is set to 32768 (not 8192), by doing the following:
> === start quote ===
> You establish a connection to the database and set the value of the page size for all new tables to 32768 as a database-wide property: 
> CallableStatement cs = 
> conn.prepareCall("CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(?, ?)"); 
> cs.setString(1, "derby.storage.pageSize"); 
> cs.setString(2, "32768"); 
> cs.execute(); 
> cs.close(); 
> === end quote ===
> 8192 is the value that is specified in the derby.properties file, which is overridden by the value (32768) specified in the database.
> (Assuming that the same database is being used).
> 2) Inconsistent use of application name:
> The case study describes persistence/precedence of a derby property by showing different ways of specifying this property when starting/running an application (embedded Derby). It seems that the intention was to show this using the same application and database. However, different application names are used throughout the case study:
> a) java -Dderby.system.home=c:\system_directory MyApp
> b) java -Dderby.system.home=c:\system_directory  -Dderby.storage.pageSize=4096 myApp
> c) java -Dderby.system.home=c:\system_directory myApplication
> Potential confusion may be avoided by using the same application name throughout the case study.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira