Le but des tables 'eav_'

Je me suis toujours demandé quelle est la signification des tableaux:

eav_entity  
eav_entity_datetime
eav_entity_decimal
eav_entity_int
eav_entity_store
eav_entity_text

Ils sont toujours vides. Ils sont créés dans les versions antérieures à 1.6 app/code/core/Mage/Eav/sql/eav_setup/mysql4-install-0.7.0.phpet plus tard, ils ont été transportés dans le script d'installation pour les versions 1.6+. /app/code/core/Mage/Eav/sql/eav_setup/install-1.6.0.0.php
J'ai vu qu'il existe un modèle de ressource lié à l'une des tables Mage_Eav_Model_Resource_Entity_Store(il y en a peut-être d'autres) mais il ne se passe rien avec / avec.

Y a-t-il une utilité à ces tables ou s'agit-il d'une autre "fonctionnalité" qui a été démarrée et non implémentée comme la version de mise en page ou le fil d'Ariane par exemple.

Je suppose que c'est en partie hérité et un modèle de «commodité» pour les développeurs d'implémenter des entités / modèles «génériques».

Comme vous l'avez dit, les tableaux associés sont généralement vides. La raison en est qu'aucune des principales entités EAV n'utilise cette structure de table d'entités "par défaut". Ce sont les tables d'entités d'une installation 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)

En utilisant le modèle Client comme exemple, nous pouvons voir que le modèle de ressource Mage_Customer_Model_Resource_Customers'étend Mage_Eav_Model_Entity_Abstract, Source .

Remarque : Avant la version 1.6, le modèle de ressource de l'entité cliente était Mage_Customer_Model_Entity_Customerégalement étendu Mage_Eav_Model_Entity_Abstract, Source .

Si nous examinons la Mage_Eav_Model_Entity_Abstractclasse, nous trouvons une getEntityTableméthode. Cette méthode est utilisée pour déterminer la table à utiliser lors de la génération de requêtes lors des opérations CRUD courantes. Une autre méthode intéressante est getValueTablePrefix. Il détermine le préfixe pour les tables de données tables « de type », *_datetime, *_decimal, *_varcharet ainsi de suite.

Jetez un œil à la source de ces méthodes ( ici et ici ).

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;
    }

Dans la méthode ci-dessus, nous pouvons voir que si le type d'entité ne définit pas de table personnalisée, il est par défaut Mage_Eav_Model_Entity::DEFAULT_ENTITY_TABLE. La valeur de cette constante est 'eav/entity', qui à son tour est transformée en eav_entitytable (en supposant qu'il n'y a pas de préfixe de table configuré dans l'application). La deuxième méthode que j'ai mentionnée retombe sur cette table en tant que préfixe si aucune n'a été configurée pour l'entité donnée. Si vous examinez les valeurs du eav_entity_typetableau de la value_table_prefixcolonne, vous remarquerez qu'elles sont toutes 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;
    }

La logique de la méthode est plutôt simple, si aucun préfixe de valeur n'est défini, utilisez le nom de la table d'entités comme préfixe.

Je suppose que depuis que ces tables sont dans Magento depuis si longtemps, il est préférable de les laisser pour une compatibilité descendante plutôt que de les supprimer purement et simplement. L'idée que je pensais qu'ils cherchaient était une structure d'entité / modèle facile à utiliser que d'autres développeurs pourraient simplement étendre quelques classes et avoir ces attributs "dynamiques" qui pouvaient être modifiés via l'administrateur (voir les produits du catalogue et les modèles client). Malheureusement, la mise en œuvre et la pratique de ce modèle ne semblent pas bien évoluer et entraînent des problèmes. Je n'ai jamais vu cette structure utilisée dans la nature, probablement en raison du manque de documentation et d'exemples d'utilisation ou de mauvaises performances.

Je ne suis pas développeur principal (ou archéologue) mais c'est ce que je comprends du code et des structures de données, j'espère que cela aidera à faire la lumière.

Considérez ce morceau de code dans le modèle de ressource EAV de base.

#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;
}

Cette méthode récupère le nom de la table d'entités de base à utiliser pour le stockage. Ainsi, pour le modèle de ressource d'un produit, cette méthode retournera catalog_product_entity(en supposant qu'aucun préfixe de nom de table n'a été défini)

Ces quatre lignes sont les plus révélatrices.

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

Si l'entité n'a pas de table, la constante suivante est utilisée

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

Cette eav/entitychaîne est ensuite utilisée pour rechercher un nom de table

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

Qui arrache le nom de la table de la config.

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

Ah ha! Si un type d'entité eav n'a pas de nom de table défini, Magento utilisera les eav_entitytables comme emplacement de stockage par défaut.

L'équipe d'ingénieurs Magento d'origine était séduite par le concept EAV - tandis que Magento moderne a réduit ce niveau, les modèles EAV étaient la solution préférée pour de nombreux problèmes.

Il semble raisonnable de supposer / spéculer que l'implémentation EAV préliminaire initiale a stocké toutes les données dans cette eav_entitytable de types centrale (un modèle courant dans les plates-formes d'entreprise), et les types d'entités sont arrivés plus tard.

Une autre possibilité (convaincante) est que cette fonctionnalité était destinée à activer les modèles CRUD "sans table". En théorie, il serait possible d'insérer les informations de type EAV correctes, de configurer vos classes de modèle / ressource / collection et d'avoir des données stockées dans ces eav_entitytables. L'éloignement de Magento de l'EAV, et l'accent mis après le lancement sur l'équipe d'ingénierie sur les fonctionnalités de l'utilisateur final ont fait que cette fonctionnalité s'estompe dans la brume. Bien que je serais curieux de savoir si cela fonctionne, je ne voudrais pas m'y fier car ce n'est pas un chemin de code qui a reçu beaucoup d'attention, et il est douteux que le TAF couvre son utilisation.

Magento utilise un modèle de données appelé "Entity Attribute Value" pour de nombreuses fonctions (clients, produits, etc.). C'est ce qui permet des attributs dynamiques dans le système sans avoir à restructurer et modifier les tables à la volée. EAV sur Wikipédia