Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Date: Tue, 26 Feb 2008 01:17:06 +0530
From: Anurag shekhar <Anurag.Shekhar@Sun.COM>
Subject: Re: [jira] Updated: (DERBY-3330) provide support for unique
 constraint
 over nullable columns
In-reply-to: <47BF2429.5060407@gmail.com>
Sender: Anurag.Shekhar@Sun.COM
To: derby-dev@db.apache.org
Message-id: <47C31B3A.6080209@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=UTF-8
Content-transfer-encoding: 7BIT
References: <953582638.1203700159726.JavaMail.jira@brutus>
 <47BF10A7.50008@sbcglobal.net> <47BF13A8.6090908@sun.com>
 <47BF1DFC.6050407@sbcglobal.net> <47BF2429.5060407@gmail.com>
User-Agent: Thunderbird 1.5.0.14pre (X11/20071023)

Army wrote:
>
> I haven't been following this discussion at all, but for what it's 
> worth, this same sort of question came up in the context of 
> DERBY-3299.  I went with the simple approach of dropping the old index 
> and creating the new one, so some logic for that kind of thing is now 
> in the 10.4 codeline.  I plan to build on that a bit more for 
> DERBY-2204, though the latter changes probably won't be in for 10.4.
>
> The changes for DERBY-3299 are entirely language-layer, but perhaps 
> it's something that can be used here?  Again, I don't really know 
> since I haven't been on top of this issue, but I thought I'd mention 
> it...
>
Looks like I will have to recreate index while setting the column to 
nullable.
The backing index, when the column was not null, will be a unique index 
but the new index is going to be unique when not null type. So it won't 
be proper to replace existing references of the current index by the new 
one. I will intead drop the index with recreate set as true (so a new 
index will be automatically created if its required) and create a new 
index for exclusive use of unique constraint.

anurag