Смысл в следующем, таблица b_user имеет уникальный индекс ix_login по полям LOGIN и EXTERNAL_AUTH_ID, где EXTERNAL_AUTH_ID может быть null что может привести к дублированию записей по составному этому индексу... к примеру:
это не баг мускула. это его типа фича
да и бог с ним ...
так вот при отключении уникальности емейлов в 1С Битрикс, при добавлении пользователя средствами
CUser::Add(array(..., "LOGIN" => "", ... ))
вылезет ошибка ... ибо проверяется уникальность логина ... автоматом!
а при
CUser::Update(123, array(..., "LOGIN" => "", ... )) - логин будет сменен без проверки на уникальность ...
достаточно весело однако обнаружить этот баг в рабочем проекте через непонятное поведение сценариев аутентификации пользователя
любителям философии:
1) не надо только укорять меня в том почему пользователь могут менять логин, в данной логике - могут! и все тут!
2) понятное дело что мне придется проверять нынче уникальность до апдейта, так что КО включать не нужно ...
просто двоякость стандарта в очередной раз внесла ложку дегтя ....
спасибо
пс. и все таки не понимаю зачем uniq index: ix_login. Либо ошибочно выбран UNIQ либо забыли отметить EXTERNAL_AUTH_ID как not 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::Add(array(..., "LOGIN" => "", ... ))
вылезет ошибка ... ибо проверяется уникальность логина ... автоматом!
а при
CUser::Update(123, array(..., "LOGIN" => "", ... )) - логин будет сменен без проверки на уникальность ...
достаточно весело однако обнаружить этот баг в рабочем проекте через непонятное поведение сценариев аутентификации пользователя
любителям философии:
1) не надо только укорять меня в том почему пользователь могут менять логин, в данной логике - могут! и все тут!
2) понятное дело что мне придется проверять нынче уникальность до апдейта, так что КО включать не нужно ...
просто двоякость стандарта в очередной раз внесла ложку дегтя ....
спасибо
пс. и все таки не понимаю зачем uniq index: ix_login. Либо ошибочно выбран UNIQ либо забыли отметить EXTERNAL_AUTH_ID как not null ....
