box: fix fkey creation together with new field names
If a complex (tuple) foreign key is added along with a new field name that participates in that foreign key, the foreign key does not work correctly. This happens because the new name of a local field is added to new_space->def->dict only in ModifySpace::alter, while before that, new_space->def->dict points to the old dictionary with old names (see ModifySpace::alter_def). So when local_field_no is initialized earlier in alter_space_do -> space_create -> tuple_constraint_fkey_init, it's unable to find the new field number in the old dictionary. Fix this by moving `new_def->dict = alter->old_space->def->dict;` from ModifySpace::alter_def() to ModifySpace::alter(). Note that, as before, we refer to the old dictionary from the new space (just put new names into it), because that dict is referenced by existing tuple formats. Closes #7652 NO_DOC=bugfix
Showing
- changelogs/unreleased/gh-7652-complex-fkey-new-field-name.md 4 additions, 0 deletionschangelogs/unreleased/gh-7652-complex-fkey-new-field-name.md
- src/box/alter.cc 42 additions, 33 deletionssrc/box/alter.cc
- test/engine-luatest/gh_6436_field_constraint_test.lua 1 addition, 1 deletiontest/engine-luatest/gh_6436_field_constraint_test.lua
- test/engine-luatest/gh_7652_complex_fkey_new_field_name_test.lua 92 additions, 0 deletions...gine-luatest/gh_7652_complex_fkey_new_field_name_test.lua
- test/engine/ddl.result 1 addition, 1 deletiontest/engine/ddl.result
- test/engine/json.result 1 addition, 1 deletiontest/engine/json.result
- test/vinyl/errinj_ddl.result 1 addition, 1 deletiontest/vinyl/errinj_ddl.result
Loading