Призначення таблиць 'eav_'

Мені завжди було цікаво, у чому сенс таблиць:

eav_entity  
eav_entity_datetime
eav_entity_decimal
eav_entity_int
eav_entity_store
eav_entity_text

Вони завжди порожні. Вони створені у версіях до 1.6 app/code/core/Mage/Eav/sql/eav_setup/mysql4-install-0.7.0.phpі пізніше. Вони перенесли на сценарій встановлення версій 1.6+. /app/code/core/Mage/Eav/sql/eav_setup/install-1.6.0.0.php
Я побачив, що існує ресурсна модель, пов’язана з однією з таблиць Mage_Eav_Model_Resource_Entity_Store(можливо, є й інші), але нічого з цим не відбувається.

Чи є користь для цих таблиць чи це інша "особливість", яка була запущена і не реалізована, як, наприклад, версія макета або адміністраторні сухарі .

Я здогадуюсь, що це частина спадщини та "зручність" для розробників для впровадження "загальних" об'єктів / моделей.

Як ви вже заявляли, пов'язані таблиці зазвичай порожні. Причина полягає в тому, що жоден з основних об'єктів EAV не використовує цю структуру таблиці "за замовчуванням". Це таблиці сутностей із встановленням 1.8:

mysql> select distinct(entity_table) from eav_entity_type;
+-------------------------+
| entity_table            |
+-------------------------+
| customer/entity         |
| customer/address_entity |
| sales/order             |
| sales/order_entity      |
| catalog/category        |
| catalog/product         |
| sales/quote             |
| sales/quote_address     |
| sales/quote_entity      |
| sales/quote_item        |
| sales/invoice           |
+-------------------------+
11 rows in set (0.00 sec)

Використовуючи модель клієнта як приклад, ми можемо побачити, що модель ресурсу Mage_Customer_Model_Resource_Customerпоширюється Mage_Eav_Model_Entity_Abstract, Джерело .

Примітка : До 1.6 ресурсна модель для юридичної особи-замовника була Mage_Customer_Model_Entity_Customerтакож розширена Mage_Eav_Model_Entity_Abstract, Джерело .

Якщо ми вивчаємо Mage_Eav_Model_Entity_Abstractклас, то знаходимо getEntityTableметод. Цей метод використовується для визначення того, яку таблицю використовувати для побудови запитів під час загальних операцій CRUD. Інший цікавий метод - це getValueTablePrefix. Він визначає префікс для таблиць для даних таблиць «типу», *_datetime, *_decimal, *_varcharі так далі.

Зазирнути до джерела цих методів ( тут і тут ).

public function getEntityTable()
    {
        if (!$this->_entityTable) {
            $table = $this->getEntityType()->getEntityTable();
            if (!$table) {
                $table = Mage_Eav_Model_Entity::DEFAULT_ENTITY_TABLE;
            }
            $this->_entityTable = Mage::getSingleton('core/resource')->getTableName($table);
        }

        return $this->_entityTable;
    }

У вищевказаному методі ми бачимо, що якщо тип сутності не визначає власну таблицю, для якої вона за замовчуванням Mage_Eav_Model_Entity::DEFAULT_ENTITY_TABLE. Значення цієї константи - це 'eav/entity', що, в свою чергу, перетворюється на eav_entityтаблицю (припускаючи, що в додатку немає налаштованого префікса таблиці). Другий метод, про який я згадував, потрапляє в цю таблицю як префікс, якщо жоден не був налаштований для даної сутності. Якщо ви вивчите значення в eav_entity_typeтаблиці для value_table_prefixстовпця, ви помітите, що вони всі NULL.

public function getValueTablePrefix()
    {
        if (!$this->_valueTablePrefix) {
            $prefix = (string)$this->getEntityType()->getValueTablePrefix();
            if (!empty($prefix)) {
                $this->_valueTablePrefix = $prefix;
                /**
                * entity type prefix include DB table name prefix
                */
                //Mage::getSingleton('core/resource')->getTableName($prefix);
            } else {
                $this->_valueTablePrefix = $this->getEntityTable();
            }
        }

        return $this->_valueTablePrefix;
    }

Логіка методу досить проста, якщо не визначений префікс значення, використовуйте ім'я таблиці сутності як префікс.

Я припускаю, що оскільки ці таблиці вже так довго існують у Magento, то краще залишити їх для будь-якої сумісності назад, ніж видаляти їх прямо. Ідея, на яку я вважаю, що вони збиралися, була простою у використанні структурою сутності / моделі, що інші розробники можуть просто розширити кілька класів і мати ці "динамічні" атрибути, які можна змінити через адміністратора (див. Каталог продуктів та моделі клієнтів). На жаль, впровадження та практика зазначеного шаблону не виглядає добре масштабним і призводить до проблем. Я ніколи не бачив, щоб ця структура використовувалася в дикій природі, ймовірно, через відсутність документації та випадків використання прикладів або низької продуктивності.

Я не основний розробник (або археолог), але це те, що я збираю з коду та структур даних, сподіваюся, це допомагає пролити трохи світла.

Розглянемо цей біт коду в базовій моделі ресурсів EAV.

#File: app/code/core/Mage/Eav/Model/Entity/Abstract.php
public function getEntityTable()
{
    if (!$this->_entityTable) {
        $table = $this->getEntityType()->getEntityTable();
        if (!$table) {
            $table = Mage_Eav_Model_Entity::DEFAULT_ENTITY_TABLE;
        }
        $this->_entityTable = Mage::getSingleton('core/resource')->getTableName($table);
    }

    return $this->_entityTable;
}

Цей метод хапає назву базової таблиці сутності, яку використовуватиме для зберігання. Отже, для моделі ресурсів продукту цей метод повернеться catalog_product_entity(якщо не було встановлено префікса імені таблиці)

Ці чотири рядки є найбільш показовими.

#File: app/code/core/Mage/Eav/Model/Entity/Abstract.php
$table = $this->getEntityType()->getEntityTable();
if (!$table) {
    $table = Mage_Eav_Model_Entity::DEFAULT_ENTITY_TABLE;
}

Якщо в сутності немає набору таблиць, використовується наступна константа

#File: app/code/core/Mage/Eav/Model/Entity.php
const DEFAULT_ENTITY_TABLE      = 'eav/entity';

Потім цей eav/entityрядок використовується для пошуку імені таблиці

#File: app/code/core/Mage/Eav/Model/Entity/Abstract.php
Mage::getSingleton('core/resource')->getTableName($table);

Яке зриває ім'я таблиці з конфігурації.

<!-- File: app/code/core/Mage/Eav/etc/config.xml -->
<entity>
    <table>eav_entity</table>
</entity>

А-а-а! Якщо для типу "entv" не встановлено ім'я таблиці, Magento використовуватиме eav_entityтаблиці як місце зберігання за замовчуванням.

Оригінальна інжинірингова команда Magento була захоплена концепцією EAV - хоча сучасний Magento масштабував цю відстань, моделі EAV були кращим рішенням для багатьох проблем.

Здається розумним припустити / розмірковувати, що початкова реалізація EAV, що зберігається, зберігає всі дані в цій eav_entityтаблиці центрального типу (загальний шаблон на корпоративних платформах), а типи об'єктів з'являються пізніше.

Інша (переконлива) можливість полягає в тому, що ця функція покликана включити «безсторонні» моделі CRUD. Теоретично можна було б вставити правильну інформацію про тип EAV, встановити модель / ресурс / класи збору та зберегти дані у цих eav_entityтаблицях. Віддалення Magento від EAV, а фокус інженерної команди після запуску на функції кінцевих споживачів означав, що ця функція згасла в туман. Хоча мені було б цікаво, якщо це працює, я не хотів би покладатися на нього, оскільки це не шлях коду, який приділяв багато уваги, і сумнівно, що TAF охоплює його використання.

Magento використовує модель даних під назвою "Value Attribute Entity" для багатьох своїх функцій (клієнтів, продуктів тощо). Це те, що дозволяє динамічні атрибути в системі без необхідності реструктурувати та змінювати таблиці на ходу. EAV У Вікіпедії