Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <9681256.1183408444485.JavaMail.jira@brutus>
Date: Mon, 2 Jul 2007 13:34:04 -0700 (PDT)
From: "Daniel John Debrunner (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-2775) DataTypeDescriptor should be immutable
 so that multiple ValueNode referring to the same DTD do not have unexpected
 state changes.
In-Reply-To: <3576793.1181229746392.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Daniel John Debrunner updated DERBY-2775:
-----------------------------------------

    Issue Type: Improvement  (was: Bug)

This is code cleanup/improvement aimed at reducing potential for bugs and fixing potentially hidden bugs.

> DataTypeDescriptor should be immutable so that multiple ValueNode referring to the same DTD do not have unexpected state changes.
> ---------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-2775
>                 URL: https://issues.apache.org/jira/browse/DERBY-2775
>             Project: Derby
>          Issue Type: Improvement
>          Components: Services, SQL
>            Reporter: Daniel John Debrunner
>            Assignee: Daniel John Debrunner
>            Priority: Minor
>             Fix For: 10.3.1.1, 10.4.0.0
>
>
> I think that modifying a DTD to change its collation may be pushing the envelope of "bug-free" code. If several ValueNode's all refer to a single DTD then changing the collation of one changes all of them. This is probably not what is required. The setCollation() pattern did copy the existing setNullablity() pattern which I think is probably also wrong and subject to bugs.
> Changing DTD to be (logically) immutable would be a much better solution, e.g. DTD.setNullability() returns a new DTD with the nullability set correctly, leaving the old one unmodified. (The method should also have a name change, setXXX() is wrong since it is not setting the state of the object it is called on). (Also such a method can return the same object if the state is unchanged). 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.