1. Главная
  2. Блоги
  3. Блог reMaster

Очистка содержимого поля CCK

Главные вкладки

Комментарии

Аватар пользователя reMaster reMaster 23 июля 2010 в 12:08

Есть конечно вариант через:

$n = node_load($nid);
$n->CCK_1 = '';
$n->CCK_1= '';
node_save($n);

Но на сильно нагруженных проектах, это убьёт просто сервер. Хотелось бы деликатнее как нибудь.

Аватар пользователя t3hk0d3 t3hk0d3 23 июля 2010 в 12:59

reMaster wrote:
Есть конечно вариант через:

$n = node_load($nid);
$n->CCK_1 = '';
$n->CCK_1= '';
node_save($n);

Но на сильно нагруженных проектах, это убьёт просто сервер. Хотелось бы деликатнее как нибудь.

Можно описать подробнее где и зачем это будет использоваться?

Другой вариант это работать напрямую с базой через UPDATE, аля

<?php
db_query('UPDATE {content_type_mynodetype} SET `field_CCK1_value` = \'\' WHERE nid = %d', $nid);
?>

Причем это, возможно не самый красивый, но уж точно самый быстрый способ, если без изврата Smile

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 23 июля 2010 в 12:58

"t3hk0d3" wrote:

db_query('UPDATE {content_type_mynodetype} SET `CCK1` = \'\' WHERE nid = %d', $nid);

а вот и не факт, тип хранения иножественных полей и единственных отличается и UPDATE лучше делать по ревизии

Аватар пользователя t3hk0d3 t3hk0d3 23 июля 2010 в 12:59

RxB wrote:
"t3hk0d3" wrote:

db_query('UPDATE {content_type_mynodetype} SET `CCK1` = \'\' WHERE nid = %d', $nid);

а вот и не факт, тип хранения иножественных полей и единственных отличается и UPDATE лучше делать по ревизии

Не спорю, но я лишь привел пример.

Аватар пользователя reMaster reMaster 23 июля 2010 в 13:34

это для афиши.
В событии порядка 25 CCK разных полей, часть нужно чистить по истечении времени.
Да, UPDATE не катит по причине, сейчас одного местоположения данных поля, а потом возможно другое.
Нужен именно механизм через API.
Пока решил вытягивать минимальное кол-во данных и обрабатывать через node_save

Аватар пользователя t3hk0d3 t3hk0d3 23 июля 2010 в 13:50

reMaster wrote:
это для афиши.
В событии порядка 25 CCK разных полей, часть нужно чистить по истечении времени.
Да, UPDATE не катит по причине, сейчас одного местоположения данных поля, а потом возможно другое.
Нужен именно механизм через API.
Пока решил вытягивать минимальное кол-во данных и обрабатывать через node_save

Надеюсь чистятся события через крон?

Аватар пользователя Xermit Xermit 23 июля 2010 в 20:49

Не знаком с тонкостями mysql, но к примеру в oracle можно пакетно множество запросов связать и потом за раз их выполнить, в принципе никто наверное не мешает в mysql склеить запросы в один и выполнить, загвоздка будет только с теми запросами, которые используют результаты предыдущих.

Если думать об оптимизации надо смотреть, а что за запросы и сколько их выполняется при node_save, может быть в drupal есть возможность пачкой изменять данные узлов, с сохраняением работы всевозможных тригеров и очисткой кэша с проставлением таймстампов о том, что данные узла изменились, а то потом пользователь так и будет продолжать видеть старую страницу.

То есть поискать функции по работе с узлами пачками

А если на код функции node_save поглядеть, то понятно почему она медленно работает, и почему еще меделенне если ее несколько раз вызывают.

http://api.drupal.ru/api/function/node_save/6

Например, у меня взывает вопрос почему время получает функциями php (аж 3 раза функцию дергают!), а не просто проставят его sql запросами в нужных полях или в mysql и при том один раз достаточно получить время и проставить его, или пусть mysql сам его проставляет мы лишь только укажем.

Далее drupal_write_record если посмотреть то каждый раз получив схему собирает sql запрос, причем собранный запрос нигде не кэшируется хотя бы по типу материала и когда вы дергаете несколько раз node_save, то drupal_write_record, каждый раз еще заново sql запрос собирает

потом тоже самое делается после обновления узла, для того чтобы в node_revisions записать

потом делается еще один запрос на обновлении каких то данных в node

затем вызывается hook-и у модулей которые ловят изменения узлов

потом возможно обновляется запись о доступе к узлу в бд

и до кучи в конце вызывается очистка кэша страниц сайта и блоков

что именно из этого тормозит больше всего надо смотреть интервалы затрат времени

но есть поле для оптимизаии если node_save выполнять хочется много раз.

и судя по всему в друпал нет апи для массового обновления данных для узлов.

и надо все таки использовать еще batch api так как это правильно

не забываем что еще до кучи надо сделать node_validate по честному

А вот и первый сюрприз я таки отыскал некую функцию для масоового обновления узлов из первого массива значениями полей из второго массива
http://api.drupal.org/api/function/node_mass_update/6

делает при этом эта функция через batch api
эта функция вызывает http://api.drupal.org/api/function/_node_mass_update_batch_process
и http://api.drupal.ru/api/function/_node_mass_update_batch_finished/6
но увы эти функции тоже вызывают node_save вот засада то

так что счастья нет, функций по массовому обновлению похоже нет, так что есть что оптимизировать

по поводу оптимизации самой функции node_save для массового сохранения есть еще патч
http://drupal.org/node/757484

далее есть некая функция drupal_execute которая к тому же работает через batch api, но я так понял она для форм расчитана?

http://blog.bytecraft.com.my/blog/kamal/2009/04/13/drupal-programmatical...
http://programmingbulls.com/nodesave-way-save-node-your-drupal-code-with...