I've always wondered what is the meaning of the tables :
eav_entity
eav_entity_datetime
eav_entity_decimal
eav_entity_int
eav_entity_store
eav_entity_text
They are always empty. They are created in versions before 1.6 in app/code/core/Mage/Eav/sql/eav_setup/mysql4-install-0.7.0.php
and later they carried to the install script for versions 1.6+ /app/code/core/Mage/Eav/sql/eav_setup/install-1.6.0.0.php
I saw that there is a resource model linked to one of the tables Mage_Eav_Model_Resource_Entity_Store
(maybe there are others) but nothing happens to/with it.
Is there any use to these tables or is this an other "feature" that was started and not implemented like the layout version or admin breadcrumbs for example.
Best Answer
My guess is that it's part legacy and a "convenience" pattern for developers to implement "generic" entities/models.
As you've stated, the related tables are usually empty. The reason being is that none of the core EAV entities use this "default" entity table structure. These are the entity tables from a 1.8 install:
Using the Customer model as an example, we can see that the resource model
Mage_Customer_Model_Resource_Customer
extendsMage_Eav_Model_Entity_Abstract
, Source.Note: Prior to 1.6 the resource model for the customer entity was
Mage_Customer_Model_Entity_Customer
which also extendedMage_Eav_Model_Entity_Abstract
, Source.If we examine the
Mage_Eav_Model_Entity_Abstract
class we find agetEntityTable
method. This method is used to determine which table to use when building queries during common CRUD operations. Another method that is of interest isgetValueTablePrefix
. It determines the prefix for the tables for data "type" tables,*_datetime
,*_decimal
,*_varchar
and so on.Peeking into the source for those methods (here and here).
In the above method we can see that if the the entity type does not define a custom table it defaults to
Mage_Eav_Model_Entity::DEFAULT_ENTITY_TABLE
. The value of that constant is'eav/entity'
, which in turn gets turned into theeav_entity
table (assuming there's no configured table prefix in the application). The second method I mentioned falls back on this table as a prefix if none has been configured for the given entity. If you examine the values in theeav_entity_type
table for thevalue_table_prefix
column you'll notice that they're allNULL
.The logic in the method is rather simple, if no value prefix is defined use the entity table name as the prefix.
I presume that since these tables have been in Magento for so long it's best to leave them in for any backwards compatibility than remove them outright. The idea that I believe they were going for was an easy to use entity/model structure that other developers could just extend a few classes and have these "dynamic" attributes that could be changed via the admin (see catalog products and customer models). Unfortunately the implementation and practice of said pattern doesn't seem to scale well and leads to problems. I've never seen this structure used in the wild, probably due to the lack of documentation and example use cases or poor performance.
I'm no core developer (or archeologist) but that's what I gather from the code and data structures, hopefully it helps shed some light.