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
