Mike Matrigali wrote:
Anurag shekhar wrote:
Army wrote:
Mike Matrigali wrote:
This would mean either dropping/recreating the index at alter time or
adding a new store interface to "convert" from old index type to new
index type.
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...
Army
Thanks Army
I think I can use your code for creating replacement index. I might
have to write one
more method to accept a new IndexRowGenerator as in this case the
index properties will be different.
anurag
Also depending on how much work this is you could incrementally check in
a patch that disallows this alter table as the code did before, and then
subsequently fix this case.
I am running a tests on patch with doesn't allows making a column
nullable if
its participating in unique constraint. I will upload this after the tests.
I will upload another patch which will allow making the columns
null able (including recreation of index in case its a unique index).
anurag
