[v1.3] Entity-Attribute-Value

[slavcodev]

Я один из скучающих

Итак мой взгляд на решение Eav (паттерн Entity Attribute Value).
Google Code

Продолжаем обсуждать

[samdark]

1. Вместо дополнительного класса PostMeta можно сразу указывать tableName параметром поведения.

2.

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

'class' => 'application.extensions.YEAVBehavior', 

можно покороче:

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

'class' => 'ext.YEAVBehavior', 

3.
Было бы удобней вместо:

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

// выбираем пост с ID = 7
        $post = Post::model()->findbyPk(7);
        // показываем атрибут textColor
        echo $post->meta->textColor;
        echo '<br />';
        // изменяем атрибут textColor
        $post->options->textColor = 'red';
        // снова показываем атрибут textColor
        echo $post->options->textColor; 

использовать привычные для моделей Yii:

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

        // выбираем пост с ID = 7
        $post = Post::model()->findbyPk(7);
        // показываем заголовок textColor
        $post->getAttributeLabel('textColor');
        echo '<br />';
        // изменяем атрибут textColor
        $post->textColor = 'red';
        // снова показываем атрибут textColor
        echo $post->textColor;
 

4. Именование методов внутри behaviour-а местами не очень логично.

Но вообще для первой версии очень хорошо. Особенно, учитывая «@todo | Go sleep ».

[slavcodev]

...

1. А дальше что мне делать с именем таблицы? Решил сделать через модель, чтоб использовать все прелести модели, такие как валидация свойств например.

2. Хорошо что напомнил, забыл про этот псевдоним.

3. Тут ничего не понял. Иду читать что за метод getAttributeLabel(), хотя кажется мы по разному видим необходимость этого поведения. getAttributeLabel() оперирует с атрибутами модели post, но такого атрибута (textColor) нет в post, к нему подобраться можно только через поведение meta (или как у вас определено в моделе post), или я не понял документацию по поведению

4. Например?! Какие именно методы плохо названы?

[slavcodev]

Попробую описать для чего это может понадобится на примере, чтоб понять в какую сторону дальше идти.

Например, у нас есть модель пользователь. У пользователя есть обязательные атрибуты: login, password, email и другие. Которые скорее всего будут все в одной таблице Users в разных столбцах: userID, userLogin, userPass, userEmail и тд (может быть и другие варианты, но я так делаю обычно). Также у пользователя могут быть, а могут не быть, n-ое количество дополнительных, необязательных атрибутов: ICQ, Skype, MSN, аккаунт в facebook и очень, очень много других. Для таких атрибутов, мне кажется не совсем логично заводить столбец в таблице Users, большинство которых будет пустое. Для этого заводим дополнительную таблицу например UsersPlus с тремя столбцами userID, userAttribute, userAttributeValue. Теперь дополнительные, не обязательные атрибуты пользователя сохраняем строчкой в таблице.

Возможно глупо объяснил, много не нужной инфы. Но у меня с этим проблемы, возможно потому что, я не совсем русский или может потому что не совсем программист по профессии, опыта нет. Поэтому и объясняю как для дет.сада.

[kosenka]

Возможно глупо объяснил, много не нужной инфы. Но у меня с этим проблемы, возможно потому что, я не совсем русский или может потому что не совсем программист по профессии, опыта нет. Поэтому и объясняю как для дет.сада.

Это очень хорошо, что так подробно расписываешь. Многие этого не делают и нам, начинающим, порой бывает сложно понять, что же хотел сказать "всевышний"

[samdark]

1. Какая такая валидация у свойств entity, attribute и value? Они же всегда и везде одинаковые.
По-моему, использование экземпляра AR для каждого поля — довольно затратно. Поведение пишется один раз, а потом используется, так что намного лучше сделать через SQL:

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

$command = $this->Owner->dbConnection->createCommand($sql);
$command->execute();
 

3. Тут я не очень корректный пример показал. Смутило, что в примере сначала $post->meta, а затем $post->options. К тому же перепутал ещё одну штуку: в поведение передаются вызовы методов, но не свойств и их геттеров-сеттеров, как я почему-то думал.

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

// Так можно. Будет вызван соотв. метод поведения
echo  $post->getField();
// А вот так уже нет.
echo $post->field;
 

4. Повникал ещё немного. Тут они, похоже, просто не очень привычные. Про нелогичные — это я, похоже, сгоряча.

[Ozzy]

Нормальное расширение. Кто-то что то делает, и это уже гуд

[slavcodev]

1. Какая такая валидация у свойств entity, attribute и value? Они же всегда и везде одинаковые.
По-моему, использование экземпляра AR для каждого поля — довольно затратно.

Валидацией я планировал проверять value, например если attribute = icq, то value = [0-9]{5,10}. Что-то такое. Но ты прав, это все можно проверять в модели формы. Однозначно будет вторая версия.

3. Тут я не очень корректный пример показал. Смутило, что в примере сначала $post->meta, а затем $post->options.

Тут моя опечатка в контролере. Добавил хинт к первому посту.

К тому же перепутал ещё одну штуку: в поведение передаются вызовы методов, но не свойств и их геттеров-сеттеров, как я почему-то думал.

Не уловил, надо проверить.

4. Повникал ещё немного. Тут они, похоже, просто не очень привычные. Про нелогичные — это я, похоже, сгоряча.

Ну приведи плиз не привычные модели, и как бы ты их назвали. Возможно твой вариант будет лучше звучать.

Нормальное расширение. Кто-то что то делает, и это уже гуд

Ну почему же кто-то, вот ты скоро два проекта запускаешь, в гугл-код есть даже трекер на Yii

[samdark]

Ещё немного пожеланий ко второй версии:
— Кодировку файлов очень хорошо было бы сменить на UTF-8.
— Расширения принято складывать в подпапки в extension. Например, в extensions/YEAV/*.

[slavcodev]

Ещё немного пожеланий ко второй версии:
— Кодировку файлов очень хорошо было бы сменить на UTF-8.
— Расширения принято складывать в подпапки в extension. Например, в extensions/YEAV/*.

- Да проблемы с кодировкой заметил после как залил на гугл-код. Почему-то думал что NetBeans работает всегда в UTF-8. Оказалось нет Только при создании проекта можно указать кодировку, уже исправил.
- Разве оно не в подпапке?

[SpiLLeR]

Не знаю насколько актуально, но я бы таблицу postMeta разбил на две:
1. attribute: id, name
2. value: id, entity, attribute_id, value

[samdark]

Зачем? Нормализация, конечно — это хорошо. Но это будет лишний JOIN.

[slavcodev]

Не знаю насколько актуально, но я бы таблицу postMeta разбил на две:
1. attribute: id, name
2. value: id, entity, attribute_id, value

В предложенной версии, когда передается модель для атрибутов это делается составлением модели на любой вкус. Все довольно гибко, но накладно по ресурсам.
В следующей версии AR, будет убран. Я думаю использовать одну таблицу. Выбирая, между хранением одинаковых имен атрибутов вместо их ID и затратами на join двух таблиц, выбираю первое. Как вариант постараюсь сделать так, чтоб пожеланию можно было легко перегрузить класс собственным.
Ваши мнения?

Другой вопрос нужен ли фильтр атрибутов? Чтоб при подключения поведения можно было указать какие атрибуты можно использовать для объекта?

[samdark]

А в чём минус фильтра?

[slavcodev]

А в чём минус фильтра?

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

[SpiLLeR]

Хочу уточнить концепцию библиотеки: планиируется хранить все атрибуты различных объектов? Будь то user, article, product?

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

[samdark]

Если заниматься нормализацией, тут ещё одна проблема всплывёт: поле name у модели User и поле name у модели Post — это разные поля.

[Dreammaker]

Ещё подумалось о i18n, как-то бы его присобачить в структуру таблицы нужно, наверное.

[samdark]

i18n вроде совершенно отдельная штука.

[slavcodev]

Хочу уточнить концепцию библиотеки: планиируется хранить все атрибуты различных объектов? Будь то user, article, product?

для этого в библиотеке будет настройка tableName и attributePrefix. Присоединяя поведение к user, можно использовать одну таблицу, для article и products другую, но одну на два объекта. Дело хозяйское. При использовании одной таблицы для двух объектов в работу приступает attributePrefix.

Про нормализацию уже ответил. Запросы к БД постараюсь вывести в отдельный метод, чтоб можно было перегрузить по желанию с использованием двух таблиц.

i18n? если имелось виду иметь разные value для одного и того же attribute в разных языках, чем плохо сохранять атрибуты под именем attribute_ru, attribute_en?