Бывает, приходится изменить uid одного или нескольких пользователей, скажем, при переносе миграции на друпал или в других случаях.
Ниже привожу SQL запрос для базовой установки друпала, для корректного изменения UID пользователя с сохранением всех прежних связей.
Перед выполнением запроса убедитесь, что пользователя с планируемым ID не существует. Если вы используете префиксы к таблицам — не забудьте о них.
UPDATE users_roles SET uid = 2 WHERE uid = 3;
# UPDATE profile_values SET uid = 2 WHERE uid = 3;
UPDATE node SET uid = 2 WHERE uid = 3;
UPDATE node_revisions SET uid = 2 WHERE uid = 3;
UPDATE files SET uid = 2 WHERE uid = 3;
# UPDATE comments SET uid = 2 WHERE uid = 3;
# UPDATE node_comment_statistics SET last_comment_uid = 2 WHERE last_comment_uid = 3
# UPDATE pool_votes SET uid = 2 WHERE uid = 3;
UPDATE authmap SET uid = 2 WHERE uid = 3;
UPDATE history SET uid = 2 WHERE uid = 3;
UPDATE sessions SET uid = 2 WHERE uid = 3;
# UPDATE accesslog SET uid = 2 WHERE uid = 3;
# UPDATE watchdog SET uid = 2 WHERE uid = 3;
SQL-запросы изменения для некоторых таблиц закомментированы, поскольку эти таблицы по умолчанию отсутствуют, однако появляются при включении соответствующих модулей из стандартного дистрибутива.
При наличии дополнительных модулей, возможно, понадобятся дополнительные запросы.
Если вам доведется производить подобные манипуляции и вы обнаружите, что я упустил какие-то таблицы, you are welcome
Кроме того, хотелось бы собрать аналогичные запросы для таблиц, создаваемых сторонними модулями.
UPD от Nikit:
Чтобы быстро найти все таблицы, которые нам нужны для апдейта (содержащие колонку %uid%), можно выполнить следующий запрос:
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = 'ИМЯ_БАЗЫ_ДАННЫХ_ДРУПАЛ'
AND COLUMN_NAME LIKE '%uid%'
Благодаря этому запросу нашел еще одну таблицу node_comment_statistic
Комментарии
<омг. туплю ночью>
в каких случаях???
что то совсем не понял зачем это нужно.
Если при миграции, то нормальный модуль миграции делает это заранее, в момент импорта пользователя в таблицу юзерс.
Какие еще остались случаи?
Разве что в познавательных.
К примеру, мне недавно пришлось менять uid при миграции с XOOPS, поскольку на XOOPS у главного модератора сайта был uid=1, и к этому id было привязано огромная куча контента. После переноса, если бы я оставил все как есть, модератору, в задачи которого в 99% случаев входит ответы на вопросы и апрув нового контента, пришлось бы сидеть под суперадмином и лицезреть в админке и в других местах уйму ненужного функционала. Кроме того, повседневное использование аккаунта с номером 1 не рекомендуется в целях безопасности. Но в первую очередь, это просто не удобно.
В закладки нах!
В основном когда принимаю под управление чужие сайты то uid прошлого админа меняю на более попроще. Так что очень часто приходится менять.
Перед тем как это сделать, следует запустить следующий код (если будет доступ конечно):
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = 'твоябаза'
AND COLUMN_NAME LIKE '%uid%'
В дефолтовом друпале 6 выдаст вот это (см. рисунки), блин фильтр тутошний лезет криво).
Stutzer, подправь.
p.s. Не факт, что какой-нибудь девелопер модулей обзовет uid в своей схеме полем userid, поэтому БЭКАП есть сила.