WithRelatedBehavior

[futbolim]

У вас юзер у которого много индектификаторов в соц. сетях = HAS_MANY. У вас же не может быть у одного индетификатора соц. сети куча юзеров?

именно так

[creocoder]

linkup
Зачем вам связь 'kSocialNets'? У вас ассоциативная таблица с дополнительными полями. Эта связь вам не нужна, т.к. у вас уже есть 'socialNets'. Что касается вопроса, то использовать связь 'socialNets' для добавления.

[futbolim]

linkup
Зачем вам связь 'kSocialNets'? У вас ассоциативная таблица с дополнительными полями. Эта связь вам не нужна, т.к. у вас уже есть 'socialNets'. Что касается вопроса, то использовать связь 'socialNets' для добавления.

Спасибо.
'kSocialNets' создал Yii, удалять не стал.

[Choo]

После последнего обновления перестало корректно работать расширение. У меня есть модель A и зависимые модели B, связь HAS_MANY. При попытке сохранить новую модель A с моделями B пишет ошибку валидации, что в моделях B не определен a_id, который у меня required. Я так понимаю, то же самое, что и в багтрекере, что помечено как исправленное. В версии 0.63 такой проблемы не было, но коммит с ней удалили с гитхаба, а в новой 0.64 снова такая же проблема.

[Benjamin]

Почему-то не сохраняет данные.

Модель:

Код: Выделить всё

/**
     * @return array relational rules.
     */
    public function relations()
        {
            ..
                'categories'    =>    array(self::MANY_MANY, 'Category','tbl_post_category(post_id, category_id)'),
              ...
            );
        } 

Контроллер:

Код: Выделить всё

public function actionUpdate()
    {
            $model = $this->loadModel();
        // Uncomment the following line if AJAX validation is needed
        // $this->performAjaxValidation($model);
        
        if(isset($_POST['Post']))
        {
        
            $model->attributes = $_POST['Post'];
            $model->update_time = time();
            foreach($_POST['Post']['categories'] as $categoryId){
                $categories[] = Category::model()->findbyPk($categoryId);
            }
            
            $model->categories = $categories;
            if($model->save() && $model->withRelated->save(array(false,'categories'=>array("id"))))
            {
                $this->redirect(array('view','id'=>$model->id));
            }
        }
        $categories = Category::model()->findAll();
        $this->render('update',array(
            'model'            =>    $model,
            'categories'    =>    $categories,
        ));
    } 

Что-то не так делаю?

[Benjamin]

Разобрался.
Дело было в неправильной передаче аргументов в метод поведения

Код: Выделить всё

public function save($runValidation=true,$data=null,$owner=null)

[Darth_Ixis]

Сейчас занимаюсь рефакторингом данного расширения(метод internalSave - 300 строк, хо-хо).

Такой вопрос, в какие ситуациях может понадобиться каскадное сохранение со связью BELONGS_TO ?

[creocoder]

Раширение уже отрефакторено. Разбивка на более мелкие нереюзабельные методы лишь снизит производительность. Что касается сохранения со связью BELONGS_TO то это может быть случай когда нужно сохранить к примеру товар и создать сразу для него категорию.

[mlapko]

creocoder, отнаследуйтесь от CBehavior, повысит производительность, в вашем behavior'е CActiveRecordBehavior не нужен.

[Darth_Ixis]

>> Разбивка на более мелкие нереюзабельные методы лишь снизит производительность.
Насколько снизит?

>> Что касается сохранения со связью BELONGS_TO то это может быть случай когда нужно сохранить к примеру товар и создать сразу для него категорию.
Почему нельзя сохранить категорию с созданным внутри товаром? Мне нужен именно четкий практический пример, я так и не смог найти удобную ситуацию для BELONGS_TO.

[creocoder]

Насколько снизит?

Неважно наскольно, важно что точно. В Yii не принято создавать методы, которые нельзя повторно использовать и которые нужны только для читаемости.

Мне нужен именно четкий практический пример, я так и не смог найти удобную ситуацию для BELONGS_TO.

На самом деле их масса. Например профиль, где пользователь может указать Страну, Регион и Город, при этом если каких либо значений нет в списке он может указать свои. Этот профиль может быть связан ещё с рядом сущностей. Сохранение в любом случае удобнее начинать с профиля. В случае с товаром аналогичная ситуация. У товара может быть ещё одна BELONGS_TO связь. И вот в этом случае сохранение не просто удобно начинать с товара, а это единственный вариант. А в чем проблема с BELONGS_TO? У вас сомнения в необходимости каскадно сохранять такие виды связей?

creocoder, отнаследуйтесь от CBehavior, повысит производительность, в вашем behavior'е CActiveRecordBehavior не нужен.

Во первых это было бы идеологически неправильно, во вторых в версии 1.1.13 появится мой и mc-bear фикс расхода памяти поведениями. Поэтому уже не актуально.

[Darth_Ixis]

>> Неважно наскольно, важно что точно. В Yii не принято создавать методы, которые нельзя повторно использовать и которые нужны только для читаемости.
Получается, в Yii плевать на программистов, которые будут читать этот код?
>> А в чем проблема с BELONGS_TO? У вас сомнения в необходимости каскадно сохранять такие виды связей?
Да, мне кажется неправильным сохранять родителя через потомка.

[mlapko]

creocoder, я с вами не согласен.
Запускать пустые события это по вашему идеологически правильно? конечно же нет, если вам не всё равно на скорость, о которой вы говорите чуть выше.
прослойка CModelBehavior, CActiveRecordBehavior расширяют только события, если вы за идеологию кода - было бы правильно их отключить добавив в ваше поведение пару строк вида так как вы не используете их.

Код: Выделить всё

public function events()
{
    return array();
}
 

Мы говорим о текущем поведении - не заглядывая в будущее. И если не сложно скиньте ссылку на ваш фикс.

[creocoder]

Получается, в Yii плевать на программистов, которые будут читать этот код?

Это ваш вывод. Мне лично подход в Yii нравится и расширение создано в строгом соответствии с ним.

Да, мне кажется неправильным сохранять родителя через потомка.

В рамках РСУБД ни о каких родителях и потомках не идет речи. Это стереотипы. Сохранение связей BELONGS_TO довольно востребовано, люди его используют.

Запускать пустые события это по вашему идеологически правильно?

И если не сложно скиньте ссылку на ваш фикс.

Фикс уже включен в фреймворк. Ждите версию 1.1.13. Никакого перекрытия events() на уровне поведения не требуется. Проблема решена качественно другим образом.

[mlapko]

Я бы не называл "качественно" что сейчас сделано, проверяя методы что они не являются protected (!$class->getMethod($handler)->isProtected()), это как ВАРИАНТ не вызывать пустые методы, но при этом создавать объекты, и вызывать функции для проверки, которые можно не создавать и не вызывать- я говорю о getMethod, new ReflectionMethod, isProtected.
При отлючение в behavior'e событий(function events() { return array(); }), если они не используются -
код:

Код: Выделить всё

        foreach($this->events() as $event=>$handler)
        {
            if(!$class->getMethod($handler)->isProtected())
                $owner->attachEventHandler($event,array($this,$handler));
        }
 

1000 раз: в 4-5 раз быстрее
events === array() 0.0080089569091797
без переопределения 0.042430877685547
100: в ~10 раз быстрее:
0.001835823059082
0.011626958847046
Так что я считаю хорошим тоном отключать события если они не используются.
Отличный пример этому: https://github.com/yiiext/activerecord- ... havior.php

[creocoder]

Я бы не называл "качественно" что сейчас сделано, проверяя методы что они не являются protected

Создатель фреймворка и комманда разрабочиков так не считает. Было долгое обсуждение этого фикса, после чего его смерджили. Предположительно ровно в таком виде это попадет и в Yii 2.

1000 раз: в 4-5 раз быстрее
events === array() 0.0080089569091797
без переопределения 0.042430877685547
100: в ~10 раз быстрее:
0.001835823059082
0.011626958847046

После фикса и речи нет о такой разнице в скорости.

Так что я считаю хорошим тоном отключать события если они не используются.

Это во первых не DRY, во вторых сопротивление инфраструктуре фреймворка. Именно поэтому фикс сделан так, чтобы создателям расширений не нужно было совершать лишних телодвижений.

Отличный пример этому

Последнее обновление было 7 месяцев назад. Думаю cebe уберет events() сразу после релиза 1.1.13.

[lancecoder]

а в 1.1.13 это поведение будет встроено в ядро?

[creocoder]

Нет

[mlapko]

После фикса и речи нет о такой разнице в скорости.

После какого ещё фикса? Если вы не заметили, я уже тестирую код из мастера, там уже включён фикс.

Я думаю не стоит продолжать спор, дело в том что мы ушли от сути с которой начинали, что ваш код отрефакторен и какие либо изменения снизят производительность, я вам дал пример который увеличит производительность, а вы упёрлись в какую то придуманную вашу идеологию. Фиксы это хорошо, но зачем делать что то, влияя на скорость и память, если этого можно не делать, дописав в компоненте пару строк.

И пожелание от себя, прочитать что такое DRY и пересмотреть ещё раз свой код.

[creocoder]

Если вы не заметили, я уже тестирую код из мастера, там уже включён фикс.

Код теста в студию, я не знаю что вы там натестировали и у вас получилась в 4-5 раз разница.

я вам дал пример который увеличит производительность, а вы упёрлись в какую то придуманную вашу идеологию

Вы дали код хака. Ещё раз повторю, фикс был сделан для того, чтобы НЕ ПЕРЕКРЫВАТЬ events(), т.к. в результате дискуссии на трекере было выяснено, что это самый убогий путь. К тому же я привел не один аспект. Наиболее важный даже не производительность, а то, что: «В Yii не принято создавать методы, которые нельзя повторно использовать и которые нужны только для читаемости».

Фиксы это хорошо, но зачем делать что то, влияя на скорость и память, если этого можно не делать, дописав в компоненте пару строк.

Если перекрыть events() было бы идеологически хотябы на грамм допустимо — это было бы сделано, а фикса бы вообще не было.

И пожелание от себя, прочитать что такое DRY и пересмотреть ещё раз свой код.

Код просматривался немало раз. Перечислять ещё раз события в events() это не DRY.

Я думаю не стоит продолжать спор... вы упёрлись в какую то придуманную вашу идеологию

Идеология, которой я руководствуюсь — это идеология инструмента для которого создано расширение. Для Zend или Symfony оно вероятно было бы сделано совершенно по другому. Что касается спора, согласен, не стоит продолжать.