Смысл в следующем, таблица b_user имеет уникальный индекс ix_login по полям LOGIN и EXTERNAL_AUTH_ID, где EXTERNAL_AUTH_ID может быть null что может привести к дублированию записей по составному этому индексу... к примеру:
Код
sel ect ID, LOGIN,EXTERNAL_AUTH_ID, NAME fr om b_user where login = 'dev@test.ru';
# ID, LOGIN, EXTERNAL_AUTH_ID, NAME
'4995', 'dev@test.ru', NULL, 'Тестовый1'
'8575', 'dev@test.ru', NULL, 'Тестовый2'
'8583', 'dev@test.ru', NULL, 'Тестовый3'
это не баг мускула. это его типа фича
Код
https://dev.mysql.com/doc/refman/5.0/en/cre ate - index.html
/* супер фильтр битрикса бьет ссылку ... кому надо по ключевым словам найдете: CRE ATE INDEX Syntax */
да и бог с ним ...
так вот при отключении уникальности емейлов в 1С Битрикс, при добавлении пользователя средствами
а при CUser::Update(123, array(..., "LOGIN" => "dev@test.ru", ... )) - логин будет сменен без проверки на уникальность ...
достаточно весело однако обнаружить этот баг в рабочем проекте через непонятное поведение сценариев аутентификации пользователя
любителям философии: 1) не надо только укорять меня в том почему пользователь могут менять логин, в данной логике - могут! и все тут! 2) понятное дело что мне придется проверять нынче уникальность до апдейта, так что КО включать не нужно ...
просто двоякость стандарта в очередной раз внесла ложку дегтя ....
спасибо
пс. и все таки не понимаю зачем uniq index: ix_login. Либо ошибочно выбран UNIQ либо забыли отметить EXTERNAL_AUTH_ID как not null ....
Штатная ф-я CUser::CheckFields() проверяет логин на уникальность в том числе и для Update(). Но у вас остается возможность изменить поля в событии OnBeforeUserUpdate уже после проверки. В этом случае вы сами должны обеспечить целостность своих данных.