db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-6220) Provide a way for users to determine the value of a Derby property
Date Tue, 04 Jun 2013 15:31:22 GMT

     [ https://issues.apache.org/jira/browse/DERBY-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Rick Hillegas updated DERBY-6220:
---------------------------------

    Attachment: derby-6220-01-aa-newSystemFunction.diff

Attaching derby-6220-01-aa-newSystemFunction.diff. This patch would add a new system function
for reporting what Derby thinks a property resolves to.

This patch simply hard-codes the analysis provided on this JIRA. The patch adds a method to
PropertyUtil which applies the rules on this JIRA to all of the documented Derby properties
except for NO_AUTO_BOOT. I omitted that property because I was a bit baffled about how to
look up the property set in service.properties when outside the store after boot time.

The new PropertyUtil method is then wrapped by a new system function:

    VARCHAR( 32672 ) SYSCS_UTIL.SYSCS_GET_PROPERTY( IN PROPERTY_NAME VARCHAR(32672) )

The new system function behaves as follows:

o Applies the rules described on this JIRA to resolve a documented property name (other than
NO_AUTO_BOOT). The result could be null. No attempt is made to further resolve a property
which is null after applying these rules. That is, no attempt is made to look up default values
hard-coded in the custom logic inside Derby modules.

o Raises an exception if passed an undocumented property (or NO_AUTO_BOOT).

The following script gives an example of running this new system function:

connect 'jdbc:derby:memory:db;create=true';

create function setSystemProperty( propertyName varchar( 32672 ), propertyValue varchar( 32672
) )
returns varchar( 32672 )
language java parameter style java no sql
external name 'java.lang.System.setProperty';

-- no value yet (call the new system function)
values syscs_util.syscs_get_property( 'derby.authentication.builtin.saltLength' );

-- set the property at the system level
values setSystemProperty( 'derby.authentication.builtin.saltLength', '50' );

-- now it has a value (call the new system function)
values syscs_util.syscs_get_property( 'derby.authentication.builtin.saltLength' );

-- set a different value in the database too
call syscs_util.syscs_set_database_property( 'derby.authentication.builtin.saltLength', '90'
);

-- but we still get the system value because of Derby's rules (call the new system function)
values syscs_util.syscs_get_property( 'derby.authentication.builtin.saltLength' );

-- unless we specify database properties only
call syscs_util.syscs_set_database_property( 'derby.database.propertiesOnly', 'true' );

-- and now we get the value stored in the database (call the new system function)
values syscs_util.syscs_get_property( 'derby.authentication.builtin.saltLength' );


A battery of tests would be needed if we decided to add this proposed new system function.

This approach could be the basis for a more complete solution. However, there is no denying
that this approach is brittle as-is. I would appreciate feedback about whether people think
this approach is work pursuing.

Touches the following files:

----------------

M       java/engine/org/apache/derby/iapi/services/property/PropertyUtil.java

The new method which hard-codes the analysis given on this JIRA. The code would look a lot
cleaner if we could switch on Strings, but that's not possible since this class needs to compile
on Java 6.

----------------

M       java/engine/org/apache/derby/impl/sql/catalog/DataDictionaryImpl.java
M       java/engine/org/apache/derby/impl/sql/catalog/DD_Version.java
M       java/engine/org/apache/derby/catalog/SystemProcedures.java

Machinery (including upgrade logic) for adding the new system procedure.

----------------

M       java/engine/org/apache/derby/loc/messages.xml
M       java/shared/org/apache/derby/shared/common/reference/SQLState.java

A new error message, raised for unknown property names.

                
> Provide a way for users to determine the value of a Derby property
> ------------------------------------------------------------------
>
>                 Key: DERBY-6220
>                 URL: https://issues.apache.org/jira/browse/DERBY-6220
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>    Affects Versions: 10.11.0.0
>            Reporter: Rick Hillegas
>         Attachments: derby-6220-01-aa-cleanupProperty.diff, derby-6220-01-aa-newSystemFunction.diff
>
>
> Derby properties can be specified as system properties, values stored in derby.properties,
and values stored in the database via the syscs_set_database_property procedure. The rules
for how these property sets interact are confusing. It would be good to provide users a way
to figure out what Derby thinks a property is set to. Maybe we could provide a builtin or
system function for this purpose.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message