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.php
y 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.
Respuestas:
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:
Usando el modelo del Cliente como ejemplo, podemos ver que el modelo de recurso se
Mage_Customer_Model_Resource_Customer
extiendeMage_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_Customer
que también se extendíaMage_Eav_Model_Entity_Abstract
, Fuente .Si examinamos la
Mage_Eav_Model_Entity_Abstract
clase, encontramos ungetEntityTable
mé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 esgetValueTablePrefix
. Se determina el prefijo para las tablas de datos para las tablas de "tipo",*_datetime
,*_decimal
,*_varchar
y así sucesivamente.Asomarse a la fuente de esos métodos ( aquí y aquí ).
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 laeav_entity
tabla (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 laeav_entity_type
tabla paravalue_table_prefix
columna, notará que son todosNULL
.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.
fuente
Considere este bit de código en el modelo de recurso EAV base.
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.
Si la entidad no tiene una tabla establecida, se usa la siguiente constante
Esta
eav/entity
cadena se usa para buscar el nombre de una tablaQue arranca el nombre de la tabla de la configuración.
Ah ja! Si un tipo de entidad eav no tiene un nombre de tabla establecido, entonces Magento usará las
eav_entity
tablas 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_entity
tabla 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_entity
tablas. 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.fuente
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
fuente