19

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.

3
  • 3
    When I started learning Magento and specially EAV, I see that these tables are empty always. I tried to search online but never got any specified answer as well. I thought that it might be a definition or reference table for other entity tables. But now I am also eagerly waiting for the answer. Thanks for this question. :)
    – MagentoBoy
    Jan 22, 2014 at 13:16
  • @MagentoBoy. I also saw then when I started working with Magento, while I was trying to wrap my head around the database. I'ts been 5+ years and I'm still puzzled.
    – Marius
    Jan 22, 2014 at 13:23
  • ..but you guys are really having good skills on magento.. Sometimes, I use your references to learn and in my code as well.. Its been about 7 to 8 months for magento and 11 months for php experience But still feel like I am a beginner for magento and need to learn alot..
    – MagentoBoy
    Jan 22, 2014 at 13:32

3 Answers 3

17

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:

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)

Using the Customer model as an example, we can see that the resource model Mage_Customer_Model_Resource_Customer extends Mage_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 extended Mage_Eav_Model_Entity_Abstract, Source.

If we examine the Mage_Eav_Model_Entity_Abstract class we find a getEntityTable method. This method is used to determine which table to use when building queries during common CRUD operations. Another method that is of interest is getValueTablePrefix. 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).

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

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 the eav_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 the eav_entity_type table for the value_table_prefix column you'll notice that they're all 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;
    }

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.

1
  • 1
    Thanks for the explanation. Good enough for me. I will try to make an entity that uses these tables, just for fun.
    – Marius
    Jan 22, 2014 at 20:58
6

Consider this bit of code in the base EAV resource model.

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

This method grabs the base entity table name to use for storage. So, for a product's resource model, this method will return catalog_product_entity (assuming no table name prefix has been set)

These four line are the most revealing.

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

If the entity doesn't have a table set, the following constant is used

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

This eav/entity string is then used to look up a table name

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

Which plucks the table name from the config.

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

Ah ha! If an eav entity type does not have a table name set, then Magento will use the eav_entity tables as the default storage location.

The original Magento engineering team was enamored of the EAV concept — while modern Magento has scaled this back, EAV models were the preferred solution for many problems.

It seems reasonable to assume/speculate the initial pre-release EAV implementation stored all data in this central eav_entity type table (a common pattern in enterprise platforms), and the entity types came along later.

Another (compelling) possibility is this feature was intended to enable "tableless" CRUD models. In theory, it would be possible to insert the correct EAV type information, setup your model/resource/collection classes, and have data stored in these eav_entity tables. Magento's move away from EAV, and the post-launch focus on the engineering team on end-user features meant this feature faded away into the mist. While I'd be curious if this works, I wouldn't want to rely on it as it's not a code path that's received a lot of attention, and it's doubtful that the TAF covers its use.

1
  • 1
    Thanks for the detailed explanation. I'm definitely going to try building a module with a "tableless" entity to see if it works. +1 from me. But I feel obligated to accept the answer provided by @beeplogic that states basically the same things. He was 5 minutes faster.
    – Marius
    Jan 22, 2014 at 20:57
-1

Magento uses a data model called "Entity Attribute Value" for many of it's functions (customers, products, etc.). This is what allows dynamic attributes in the system without having to restructure and alter the tables on the fly. EAV On Wikipedia

1
  • Thanks, but this does not really answer the question. What entity uses the tables mentioned in the question? I wasn't talking about customer, products or categories.
    – Marius
    Jan 22, 2014 at 15:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.