Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Tue, 4 Jun 2013 14:43:22 +0000 (UTC)
From: "Rick Hillegas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12646802.1368107994754.64474.1370357002188@arcas>
In-Reply-To: <JIRA.12646802.1368107994754@arcas>
References: <JIRA.12646802.1368107994754@arcas>
Subject: [jira] [Commented] (DERBY-6220) Provide a way for users to
 determine the value of a Derby property
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13674449#comment-13674449 ] 

Rick Hillegas commented on DERBY-6220:
--------------------------------------

Thanks for helping me think through this problem, Dag. Right now, each property is handled by custom logic. The custom logic is scattered across Derby's modules. Some support for common search orders has been isolated in PropertyUtil.

A less brittle approach to property management might be to centralize all property determination. That is, to move the custom logic from the modules into PropertyUtil. Then we could write a new system function which called the centralized logic. That would give us confidence that we were telling users the real, effective values of properties. As we added more properties over time, we could be confident that we were still aligning Derby and the user's understanding of property values.

At first blush, this looks like a fair amount of work, for a couple reasons:

o There are a lot of properties to isolate.

o Sometimes custom logic looks for properties in a PersistentSet (the transaction), sometimes in a vanilla Properties object, and sometimes in a DoubleProperties object which layers the PersistentSet on top of service.properties.

o The custom logic also supplies defaults for missing properties. Users probably want to know what those defaulted values are too. However, those defaults are private to the modules and exporting them could be seen as an encapsulation issue.

I'm not sure that this problem is worth that much effort compared to other projects we could work on. Cheaper solutions include:

1) Stop now. Point users at this JIRA when they wonder what Derby thinks a property resolves to.

2) Copy this information to the wiki and point curious users there.

3) Add a system function which captures the rules described on this JIRA.

All of these cheap solutions are brittle. There is no guarantee that I haven't made mistakes in my analysis. Even if my analysis is largely correct, there's no guarantee that the custom logic won't change underneath us as time goes on. None of the cheap solutions address those problems.

That said, I have mocked up solution (3) and will attach it to this JIRA soon. It could serve as an incremental basis for the complete solution if someone wants to tackle that in the future. But it might just be a waste of time because of its brittleness. I would appreciate your feedback.

Thanks,
-Rick

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