SQL Error in Commit 10156-10159

[antiroot]

sql/characters.sql was changed to add some new fields and dropped some old ones, one of the fields dropped was part of the PRIMARY KEY

Rev. 10156 on line 386 of sql/characters.sql

PRIMARY KEY (`guid`,`spell`,`effect_index`)

If someone is creating this table for the first time this query will fail because effect_index does not exist

I do not know if a new field needs to be added (effIndexMask if it does?) or if only guid+spell is enough, so i cannot provide a patch

[Darkruler]

sql/characters.sql was changed to add some new fields and dropped some old ones, one of the fields dropped was part of the PRIMARY KEY

Rev. 10156 on line 386 of sql/characters.sql

PRIMARY KEY (`guid`,`spell`,`effect_index`)

If someone is creating this table for the first time this query will fail because effect_index does not exist

I do not know if a new field needs to be added (effIndexMask if it does?) or if only guid+spell is enough, so i cannot provide a patch

For as far as i can see, effect_index doesn't need a replacement

and the issue you're talking about is not only a problem in sql/characters.sql

but also in

sql/updates/10156_01_characters_character_aura.sql

and

sql/updates/10156_02_characters_pet_aura.sql

needed is:

ALTER TABLE character_aura DROP PRIMARY KEY;
ALTER TABLE character_aura ADD PRIMARY KEY (`guid`,`spell`);
ALTER TABLE pet_aura DROP PRIMARY KEY;
ALTER TABLE pet_aura ADD PRIMARY KEY (`guid`,`spell`);

[antiroot]

The update files do not create the table though, when the update queries drop the field it drops it from the Primary Key as well so they are not an issue as far as I can tell.

besides if the updates were an issue, then that would require a new update file not patching an old one

Edit: @darkruler Yeah I agree with your code you provided above, dropping the key and then recreating it would be a good way to do it, just dropping the column I'm not sure if the index gets rebuilt, but recreating the key altogether would rebuild the index (if there were actually any data in the table that is)

[Darkruler]

The update files do not create the table though, when the update queries drop the field it drops it from the Primary Key as well so they are not an issue as far as I can tell.

besides if the updates were an issue, then that would require a new update file not patching an old one

True, i wasn't saying that they needed to adjust the existing ones

and the primary key is still present after using the update sql, having a primary key (which should be an unique identifier ) that doesn't even exist...now that isn't right

[laise]

fixed in [10160], Thanks for report =)