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] [Commented] (DERBY-6220) Provide a way for users to determine the value of a Derby property
Date Tue, 04 Jun 2013 14:43:22 GMT

    [ 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

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

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.


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

View raw message