Массовое изменение телефонов в битрикс коробка через БД?
Собственно есть битрикс24 коробка.
Есть задача привести все номера телефонов к единому стилю +7.....
(сейчас сборная солянка 8, +7, 7)
Вижу несколько путей решения. Наверное один из правильных будет - используя REST пробежаться по всем контактам, посмотреть их номера телефонов, если они соответствуют определенному regexp - изменять их.
Но это долго (в том плане что делать всю это логику обработки для REST). Можно всё тоже самое сделать в разы быстрее в 3-4 sql запроса. Условно на REST решение у меня уйдет примерно 4-6 часов, а через SQL - за 20-30 минут .
Битрикс крайне не рекомендует работать напрямую с базой данных. Для меня не критично, что в карточке сущности, в истории не будет отображаться что был изменен телефон, т.е. этот момент я могу игнорировать. Как считаете, на сколько будет критичным, если изменить номер телефона через БД а не средствами REST?
Да, я знаю что можно включить логирование запросов mysql, сделать изменение данных в битриксе, посмотреть какие прошли за это время. Но мне честно говоря лень разбирать эти запросы + там битрикс каждый чих в бд пишет + проект работает 24\7 и там постоянно какие то действия, так что мне лень будет разбирать простыню запросов чтобы понять какие запросы сопутствующие, а разворачивать голый битрикс и делать тоже самое честно говоря тоже не особо хочется.
P.S. знаю что номера телефонов хранятся в таблице b_crm_field_multi
mayton2019, вредный совет) Мне не нужно добавить +7 в начало каждой записи, у меня немного в другом задача состоит. В целом у меня нет вопроса - как составить запрос, это я знаю как сделать. У меня вопрос - на сколько плохо будет, если я начну менять телефоны в БД, а не средствами битрикса .
И да, там структура немного иная. Лень писать сделаю скрином
Если обновлять информацию "мимо комплекса" - то будет следующее.
1) Не будет зафиксирован аудит изменений. Тоесть не будет следа модификации телефона. Это плохо
с точки зрения инфобезопасности. Кто будет наказан в этой ситуации - спроси у своего менеджера.
2) Не будут обновлены кеши приложения. UI тоже не будет знать о том что телефон меняется. Что в этот
момент он будет рисовать - это загадка. Зависит от того как UI был написан. Может ничего страшного
и не будет но я-бы советовал ребутнуть всех клиентов и Citrix, и все remote desktops.
3) Обычно в двузвенках модификация таблиц идет через пакет процедур (хранимок или кода
в приложении и изменения атрибутов вызывают автомтические действия). Кроме аудита
может быть еще много чего сделано. Обновления справочников и прочее.
Вообще я не спец в битрикс поэтому надо читать документацию по нему.
mayton2019, во, это уже ближе к истине.
1) я могу пренебречь аудитом изменений, т.к. это внутренний проект. Следовательно если кого то и придется наказывать - то только самого себя, т.к. данная задача решается мной единолично. В случае оплошности, есть как и полные бэкапы так и инкрементные, которые позволят откатить только затронутые записи. Впрочем я все равно не буду этого сразу на живой базе, а сначала отработаю на копии таблицы.
2) на сколько я помню, эти записи не кэшируются, они относятся к high load (внутренняя терминология в битриксе) блокам и при каждом запросе берутся из таблицы. Но тут спасибо за наводку, может быть и будет полезным обновить кэш после изменений в БД.
Цитрикс и битрикс совершенно разные продукты. Битрикс это CRM, а цитрикс это виртуальные рабочие места.
3) вот как раз этот момент меня больше всего и беспокоит, как я написал в вопросе - мне просто лень включать логирование запросов и проводить анализ того, какие запросы связаны с основным запросом по изменению телефона. Некоторые процедуры я знаю, какие битрикс совершает при изменении номера телефона, но не знаю полноту всей картины моих знаний, возможно там есть такие процедуры которые обязательно нужно проводить, а я их не учитываю. Мне бы в этом случае помог анализ связанных запросов, но это будет иррационально, по времени получится выгодней сделать обновление через rest, чем проводить такой аудит и уже менять в БД.
Документация в этом плане будет достаточно скудной, т.к. они категорически не приветствую работу с БД напрямую. Поэтому тут даже не в доку лезть, а изучать код системы, что по времени будет совсем убийственным, особенно с особенностями написания этого продукта.
Если аудит изменений не требуется, то вообще не вижу проблемы. Остановите все приложения/сервисы/демоны, кроме MySQL-сервера. Измените данные (в принципе, тут и одного запроса достаточно). Перегрузитесь.
Ну и - я почти убеждён, что найдутся номера телефонов, не пролезающие вообще ни под какой шаблон. А потому я бы выгрузил список всех телефонов в отдельную таблицу, добавил поле эталонного отображения, не спеша заполнил его, с учётом избыточно кривого ввода, а потом провёл вышеописанную процедуру. Чем хорош такой подход - если придётся заменять БД на новую со свежими данными, то 99% работы по нормализации номеров уже выполнена.
CREATE TABLE tmp_phone (old_value VARCHAR, new_value VARCHAR);
INSERT INTO tmp_phone (old_value)
SELECT DISTINCT value
FROM b_crm_field_multi
WHERE complex_id LIKE 'PHONE_%';
-- обновление поля new_value любыми средствами, запросами или вручную, независимо от битрикса
UPDATE b_crm_field_multi t1
JOIN tmp_phone t2 ON t1.value = t2.old_value AND t2.complex_id LIKE 'PHONE_%'
SET t1.value = t2.new_value;
Akina,
Что касается аудита изменеий, то здесь я сам себе хозяин и господин. Поэтому в данном случая у меня есть возможность этим пренебречь. На счет остановки сервисов немного спорно, разве что, для того чтобы не столкнуться с блокировкой записей, но я это буду делать в то время, когда работа с этими полями (считай таблицами) не будет происходить, поэтому блокировка крайне маловероятна.
Определенно точно, Вы правы. В таблице существуют номера, которые не подпадут под стандартный шаблон изменений.
Например встречаются такие маски:
++7
+77
77
Изредка встречаются международные маски, условно
+3
3
+971
Моя задача, в данном случае немного проще - привести маски 7 и 8 к виду +7
Я не исключаю варианты, что могут быть номера начинающиеся на 7 условно 729(Израиль) 773(Уругвай), но в моем понимании произойдет замена 729 на +729 поэтому это будет даже правильным. Вышеописанные исключения будут приводить в порядок в ручном режиме и уже не я.
Спасибо за примеры запросов, но я думаю не дергать целиком всю таблицу, а получить именно записи который подходят под мою задачу (не содержит +7 и начинается с 7 или 8)
Дальше провести замену.
Провести выборочную проверку.
Дальше обновить записи.
С написанием запросов сложностей нет, меня больше волновало что я мог не учесть на стороне битрикса. (Например сброс кэша) Или может быть данные хранятся не только в одной таблице, но и в каких то других нужно проводить замену (я делал поиск по всей бд, вроде как только в одном месте нашлось упоминание уникального номера)
ак я написал в вопросе - мне просто лень включать логирование запросов и проводить анализ того, какие запросы связаны с основным запросом по изменению телефона.
Ты уже несколько раз напомнил всем как тебе лень что-то делать. Зато ты напряг целый форум людей.
Постарайся все таки меньше лениться.
mayton2019, в данном случае лень подразумевает более рациональное использование своего времени, в данном случае я стою перед выбором - потратить Х часов на REST решение, или потратить Y часов на SQL решение, где мне очевидно что X>Y. Но есть определенные подводные камни, которых я опасаюсь с точки зрения самого битрикса, собственно я прошу поделиться опытом по решению подобной задачи. Будь я уверен, что можно работать с таблицей b_crm_field_multi без серьезных рисков повлиять на другую логику - я бы и не задавал этот вопрос тут. Если прочитать внимательно вопрос, то он звучит так -
Как считаете, на сколько будет критичным, если изменить номер телефона через БД а не средствами REST?
Всё остальное это дополнительные вводные и\или мои проработки по этой задаче. + какими условиями я могу пренебречь.
Я же не прошу за меня выполнять мою работу, не прошу писать за меня запросы к тому же SQL, я даже примеры этих запросов не спрашиваю)
Это всё равно что появился бы вопрос, по тому же битриксу где спрашивали - как можно работать с рабочим графиком в битриксе? Я бы поделился опытом и сказал - в b_timeman_work_shift создаются расписания (но их лучше создавать через битрикс) а с таблицей b_timeman_work_shift_plan можно работать и вносить изменения через SQL запросы без оглядки на дополнительную логику битрикса, т.к. в этом случае дополнительных связанных запросов нет. Т.к. через REST нужный функционал недоступен, и остается только способ писать собственный обработчик на D7 связанный с логикой битрикса. А если не нужно массовое решение, а как микросервис, то подход работы с БД битрикса - будет предпочтительнее.
На счет остановки сервисов немного спорно, разве что, для того чтобы не столкнуться с блокировкой записей
Блокировки меня не колышут от слова "совсем".
Предлагаемая остановка сервисов же нужна для того, чтобы исключить проблемы, которые описывает mayton2019 - рассинхрон того, что лежит в базе, и того, что себе на этот счёт думает приложение, на практике это может вылиться в весьма экзотические проблемы, и хорошо если без разрушения данных.
А что до обновления не всех, а избранных - ну так не вижу проблемы. Делов-то - добавить соотв. условия во WHERE. Хотя я бы выгружал всё, и просеивал уже на стадии формирования форматированных значений - ну а хоть бы и автоматическим копированием старого значения в поле для нового при соответствии шаблону. Размер в этой операции не лимитирует, а вот полнота массива данных никому ещё не вредила.
