El propósito de las tablas 'eav_'

19

Siempre me he preguntado cuál es el significado de las tablas:

eav_entity  
eav_entity_datetime
eav_entity_decimal
eav_entity_int
eav_entity_store
eav_entity_text

Ellos siempre están vacíos. Se crearon en versiones anteriores a la 1.6 app/code/core/Mage/Eav/sql/eav_setup/mysql4-install-0.7.0.phpy luego se llevaron al script de instalación para las versiones 1.6+ /app/code/core/Mage/Eav/sql/eav_setup/install-1.6.0.0.php
. Vi que hay un modelo de recurso vinculado a una de las tablas Mage_Eav_Model_Resource_Entity_Store(tal vez hay otras) pero no sucede nada con él.

¿Hay algún uso de estas tablas o esta es otra "característica" que se inició y no se implementó como la versión de diseño o las migas de pan del administrador, por ejemplo.

Marius
fuente
3
Cuando comencé a aprender Magento y especialmente EAV, veo que estas tablas están siempre vacías. Traté de buscar en línea pero nunca obtuve una respuesta específica también. Pensé que podría ser una definición o tabla de referencia para otras tablas de entidades. Pero ahora también estoy esperando ansiosamente la respuesta. Gracias por esta pregunta :)
MagentoBoy
@MagentoBoy. También vi cuando comencé a trabajar con Magento, mientras trataba de entender la base de datos. Han pasado más de 5 años y todavía estoy perplejo.
Marius
... pero ustedes realmente están teniendo buenas habilidades en magento ... A veces, uso sus referencias para aprender y también en mi código ... Han pasado entre 7 y 8 meses para magento y 11 meses para experiencia en php. soy un principiante para magento y necesito aprender mucho ..
MagentoBoy

Respuestas:

17

Supongo que es parte del legado y un patrón de "conveniencia" para que los desarrolladores implementen entidades / modelos "genéricos".

Como has dicho, las tablas relacionadas generalmente están vacías. La razón es que ninguna de las entidades centrales de EAV utiliza esta estructura de tabla de entidades "predeterminada". Estas son las tablas de entidades de una instalación 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)

Usando el modelo del Cliente como ejemplo, podemos ver que el modelo de recurso se Mage_Customer_Model_Resource_Customerextiende Mage_Eav_Model_Entity_Abstract, Fuente .

Nota : Antes de 1.6, el modelo de recursos para la entidad del cliente era el Mage_Customer_Model_Entity_Customerque también se extendía Mage_Eav_Model_Entity_Abstract, Fuente .

Si examinamos la Mage_Eav_Model_Entity_Abstractclase, encontramos un getEntityTablemétodo. Este método se utiliza para determinar qué tabla usar al generar consultas durante operaciones CRUD comunes. Otro método que es de interés es getValueTablePrefix . Se determina el prefijo para las tablas de datos para las tablas de "tipo", *_datetime, *_decimal, *_varchary así sucesivamente.

Asomarse a la fuente de esos métodos ( aquí y aquí ).

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

En el método anterior, podemos ver que si el tipo de entidad no define una tabla personalizada, su valor predeterminado es Mage_Eav_Model_Entity::DEFAULT_ENTITY_TABLE. El valor de esa constante es 'eav/entity', que a su vez se convierte en la eav_entitytabla (suponiendo que no haya un prefijo de tabla configurado en la aplicación). El segundo método que mencioné recae en esta tabla como un prefijo si no se ha configurado ninguno para la entidad dada. Si examina los valores en la eav_entity_typetabla paravalue_table_prefix columna, notará que son todos 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 lógica en el método es bastante simple, si no se define un prefijo de valor, use el nombre de la tabla de entidad como prefijo.

Supongo que, dado que estas tablas han estado en Magento durante tanto tiempo, es mejor dejarlas para cualquier compatibilidad con versiones anteriores que eliminarlas por completo. La idea que creo que buscaban era una estructura de entidad / modelo fácil de usar que otros desarrolladores podrían simplemente extender algunas clases y tener estos atributos "dinámicos" que podrían cambiarse a través del administrador (consulte el catálogo de productos y modelos de clientes). Lamentablemente, la implementación y la práctica de dicho patrón no parece escalar bien y genera problemas. Nunca he visto esta estructura utilizada en la naturaleza, probablemente debido a la falta de documentación y ejemplos de casos de uso o bajo rendimiento.

No soy un desarrollador central (o arqueólogo), pero eso es lo que deduzco del código y las estructuras de datos, espero que ayude a arrojar algo de luz.

beeplogic
fuente
1
Gracias por la explicación. Suficientemente bueno para mi. Intentaré crear una entidad que use estas tablas, solo por diversión.
Marius
6

Considere este bit de código en el modelo de recurso EAV 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;
}

Este método toma el nombre de la tabla de entidad base para usar para el almacenamiento. Por lo tanto, para el modelo de recursos de un producto, este método devolverá catalog_product_entity(suponiendo que no se haya establecido un prefijo de nombre de tabla)

Estas cuatro líneas son las más reveladoras.

#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 la entidad no tiene una tabla establecida, se usa la siguiente constante

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

Esta eav/entitycadena se usa para buscar el nombre de una tabla

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

Que arranca el nombre de la tabla de la configuración.

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

Ah ja! Si un tipo de entidad eav no tiene un nombre de tabla establecido, entonces Magento usará las eav_entitytablas como la ubicación de almacenamiento predeterminada.

El equipo de ingeniería original de Magento estaba enamorado del concepto EAV, mientras que Magento moderno ha reducido esto, los modelos EAV fueron la solución preferida para muchos problemas.

Parece razonable suponer / especular que la implementación EAV previa al lanzamiento inicial almacenó todos los datos en esta eav_entitytabla de tipos central (un patrón común en las plataformas empresariales), y los tipos de entidad aparecieron más tarde.

Otra posibilidad (convincente) es que esta característica estaba destinada a habilitar modelos CRUD "sin mesa". En teoría, sería posible insertar la información correcta del tipo EAV, configurar sus clases de modelo / recurso / colección y tener los datos almacenados en estas eav_entitytablas. El alejamiento de Magento de EAV, y el enfoque posterior al lanzamiento en el equipo de ingeniería en las características del usuario final significaron que esta característica se desvaneció en la niebla. Si bien sería curioso si esto funciona, no me gustaría confiar en él, ya que no es una ruta de código que ha recibido mucha atención, y es dudoso que el TAF cubra su uso.

Alan Storm
fuente
1
Gracias por la explicación detallada. Definitivamente voy a intentar construir un módulo con una entidad "sin tabla" para ver si funciona. +1 de mi parte Pero me siento obligado a aceptar la respuesta proporcionada por @beeplogic que establece básicamente las mismas cosas. Fue 5 minutos más rápido.
Marius
-1

Magento utiliza un modelo de datos llamado "Valor de atributo de entidad" para muchas de sus funciones (clientes, productos, etc.). Esto es lo que permite atributos dinámicos en el sistema sin tener que reestructurar y alterar las tablas sobre la marcha. EAV en Wikipedia

Adam R.
fuente
Gracias, pero esto realmente no responde la pregunta. ¿Qué entidad usa las tablas mencionadas en la pregunta? No estaba hablando de clientes, productos o categorías.
Marius