Mike Matrigali <[email protected]> writes: > You seem to have found a number of problems with the new code that > tries to implement the unique constraint with multiple nulls. I > definitely missed the deleted row case when reviewing that code, and > had assumed it > just ever needed to search one row left and right. > > I am now wondering if it would be better to make this code work the same > as the existing code in the regular unique case. That code makes sure > there is always only ONE row with the given key (not including the row > id). It manipulates the search params so that either that exact row > is found or it positions in the right place to do the insert. > > It does have some tricky code for when it finds a matching row, > especially if it is marked deleted, but that code has been working for > a long time now.
(By the way, do you think this tricky code may be the cause of DERBY-4032? There we have one deleted row hiding another row with the same key in a unique index.) > The approach would be something like: > o If there is a null in the key then just do the insert normally into > the non-unique table, using all keys. > o If no null, then need to change the search params to only use leading > columns and to not allow exact match - this means changing the > existing code which would use the > tables information which would say to use all columns. > o and then if match use the existing code for unique tables in this case. > > Let me know what you think. Is this a better approach or should we > patch up the new code? Are you interested in doing this? If not I > may have time to do this. Your suggestion sounds like a more robust approach than the current one to me. I only planned to fix DERBY-4028 and DERBY-4081 for 10.5, as they seem to be rather easy to fix. So if you have time, feel free to pick this up. Are you aiming for 10.5? If so, I should probably not check in the fixes that I have posted. Otherwise, I could check them in now so that we improve the situation for 10.5 too. -- Knut Anders
