Задать вопрос
@evilelf
Тупой, руки из жопы, кодю за зп и т.п. и т.д.

Как узнать кол-во изменённых строк в yii?

Все отличного пятничного дня!)

Второй месяц работаю с yii, очень нравится)
Столкнулся с проблемой в работе с yii.
Кто, как решил проблему?)

Вот такой кусок кода:
$sql = "INSERT INTO  {{".$table."}} ( ".$arrKey['KEY'].", ". implode(', ', $column) ." ) VALUES ".implode(',',$question_marks)." ON DUPLICATE KEY UPDATE meta_val = VALUES(meta_val);";
$command=Yii::app()->db->createCommand($sql);
$res=$command->execute();


в $res у меня возвращается "0", если ячейки были обновлены. Но если строки были добавлены, то возвращается 1.

Как узнать кол-во затронутых строк?
Спасибо!)
  • Вопрос задан
  • 616 просмотров
Подписаться 3 Оценить Комментировать
Пригласить эксперта
Ответы на вопрос 1
Hesed
@Hesed
Критерий "on duplicate key update" есть только в MySQL (и форках) и его не шибко хорошо использовать, равно как и хардкодить SQL-запрос, когда есть DAO/AR. Если по существу, то "on duplicate key update" согласно официальной документации возвращает 1, если ряд был вставлен и 2, если обновлён. Поскольку это поведение самого MySQL, то средствами Yii это не обойти.

Для решения задачи, я бы пересмотрел само выражение и подход к написанию запросов. Например:
// Ищем, существует ли запись с ключом $id
$model = MetaModel::model()->findByPk($id);

// Если записи нет, мы будем делать insert
if(!$model) {
    $model = new MetaModel();
    // Присваиваем атрибуты. Позаботьтесь о том, чтобы массив $attrs содержал их
    $model->attributes = $attrs;
    $res = $model->save();
}
else {
    $res = Yii::app()->db->createCommand()
        ->update('{{table}}',        // название таблицы
            array(
                'meta_val'=>':meta', // какое поле
            ), 
            'id=:id',                // where id = ...
            array(
                ':id' => $id,        // param binding
                ':meta' => 'blablabla'
            )
        )
        ->execute();
}

echo intval($res).' rows affected';


Код написан вслепую и не тестировался. Его однозначно необходимо заточить под свои нужды, я лишь предлагаю свой вариант. Более громоздко? Да, но мы:
  • избавляемся от привязки к MySQL;
  • от довольно пагубной привычки писать "чистый" SQL, когда в нашем распоряжении есть такие инструменты, как ActiveRecord и конструктор запросов
  • приучаемся использовать param binding, что, впрочем, не избавляет от необходимости sanitize'ить данные


P.S. Это решение "в лоб", требующее минимально менять существующий код. По-хорошему, конечно, такие задачи надо решать до запроса на уровне сценариев. Или навешивать behavior.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы