• Entity type by code. Requesting entity type “catalog_category” will return a Mage_Eav_Model_Entity_Type object with information about attribute model class, additional attribute table (catalog/eav_attribute) and so on.
• Codes of all attributes of the entity type, in an array.
• Attribute object or an entire preloaded attribute collection.

• Attribute groups, which are accessible by id or name. Catalog attributes are organized into groups, and these data contain their IDs and names, e.g. “64” or “description”.
• Attribute set id or name. Product attributes can be assigned to a set, which then is applied to products that share the same attributes. Sets could be, for example, “furniture”, “CPUs”, or “jewelry”.
• List of attributes that product lists can be sorted by (sortable attributes).
• List of attributes that can be used in product listings (the attribute with this property will get into the flat table and can be accessed from the product listing collections)
• Product type names or product types. Product types (for example, simple, configurable, or downloadable) can have different attributes even if they share the same attribute set with other types. Each product attribute can be set to apply for certain product types. Product types are defined in the config node global/catalog/product/type.
• Attribute sets and attribute groups as object collections.

• Getting the attribute’s model in a category object
• Loading attributes used to sort product lists by in the navigation toolbar
• Checking if customer address attribute *prefix* is visible before displaying it in front of the customer name

Mage EAV Entity Resource Models

The table eav_entity_type lists 28 entity types in Magento (v. 1.7.0). But only four of them are implemented as EAV. For these entity types Magento offers resource models that connect them to their data. This simplified diagram shows the inheritance hierarchy of Magento entity resource classes.

In the center of this hierarchy stands the class Mage_Eav_Model_Entity_Abstract. It implements interface Mage_Eav_Model_Entity_Interface, which currently is empty. But what’s more important is that this class extends Mage_Code_Model_Resource_Abstact. This makes it a resource model, even if a diversion from the common class naming convention is a bit confusing. As a resource model Mage_Eav_Model_Entity_Abstract contains all the functionality necessary to access data sources, i.e. the database.As an abstract class Mage_Eav_Model_Entity_Abstract can’t be instantiated, and the real work is performed by its extensions. Of the four EAV entity types catalog_category and catalog_product use resource models that do not extend Mage_Eav_Model_Entity_Abstract directly. Another abstract class Mage_Catalog_Model_Resource_Abstract comprises functionality that is shared by both catalog entity types. Type-specific resource model extensions are Mage_Catalog_Model_Resource_Category and Mage_Catalog_Model_Resource_Product. Other two EAV entity types, customer and customer_address have their own resource model classes: Mage_Customer_Model_Resource_Customer and Mage_Customer_Model_Resource_Address.

Mage_Eav_Model_Entity_Abstract also has extensions in the Mage_Sales module. I, however, did not encounter these classes in action. Instead, the sales entities have resource models that connect them to flat tables. It has probably been done to improve performance. EAV sales entities such as order or quote would be loaded and manipulated during the checkout, where performance is demanding, especially in heavy-load shops. EAV would have added too much overhead in this critical process. Cashing EAV data, like in the catalog, is problematic in the checkout; so using flat tables in the Mage_Sales module is simply more practical. The EAV functionality, which is left in this module, exists presumably for backward compatibility.

As resource models the extensions of the Mage_Eav_Model_Entity_Abstract class are tasked with loading, updating, and saving EAV entities. When doing that EAV resource models bind the EAV entity model functionality with the functionality of its attributes’ models. For every operation on data (after_load, validate, before_save, after_save, before_delete, after_delete) an EAV resource model performs “attribute walking” (yep, the function is called walkAttributes()). It loads all the object’s attributes and calls a corresponding function of their data models. So, for example, when deleting a customer, not only the customer entity will be deleted from the customer_entity table, but also every customer attribute will be called up in a loop, and its data model will delete attribute data for the given customer id.

There is one more resource model extending Mage_Eav_Model_Entity_Abstract. The class Mage_Eav_Model_Entity is a default resource model and is used in cases when entity type is not yet defined, and only to set the entity type. Then a type-specific resource model takes control.

Magento EAV Attributes

Magento implements its EAV attributes as models, whose classes comprise the following inheritance hierarchy.

Like any other Magento model EAV attributes have Mage_Core_Model_Abstract as the starting point of the class hierarchy. The EAV-specific functionality is first defined in the abstract class Mage_Eav_Model_Entity_Attribute_Abstract. It extends the interface Mage_Eav_Model_Entity_Attribute_Interface, which theoretically would be setting functional requiremets for the EAV attribute models, but is empty. Further functionality refinement comes in the class Mage_Eav_Model_Entity_Attribute. This class can be instantiated and sometimes is used in a singleton role to provide access to its array of all attribute IDs. Whenever the system needs to find out, which attribute_code (attribute name) refers to what attribute ID it calls Mage_Eav_Model_Entity_Attribute::getIdByCode() (the actual function is inherited and resides in the abstract class, so don’t be confused by this link). But more often this class is employed as a default attribute model. When an attribute is being used in isolation from an entity type, its model is an instance of the `Mage_Eav_Model_Entity_Attribute class.

The concrete implementations of attribute models of the main entity types are further down the hierarchy. Thus attributes of the customer entity type have the Mage_Customer_Model_Attribute model. Catalog entity types also have their own model called Mage_Catalog_Model_Resource_Eav_Attribute. The naming convention, unfortunately, isn’t always straightforward in Magento. In this case despite the word “Resource” in its name, the class is not a resource model. It is a descendant of the Mage_Core_Model_Abstract class (indirectly, the inheritance path is Mage_Eav_Model_Entity_Attribute -> Mage_Eav_Model_Entity_Attribute_Abstract -> Mage_Core_Model_Abstract). Its resource model is actually Mage_Catalog_Model_Resource_Attribute.

Another attribute model in the Mage_Catalog module is Mage_Catalog_Model_Entity_Attribute. This one is almost unused. The only time you come across it is in the user wish list grid in the shop’s administration backend. There it is used only to load the product name attribute via the loadByCode function, which it has inherited anyway. Ignore this class.

Encapsulating attribute metadata and providing the system with an access to it is the single most important role played by attribute models. In this task metadata is presented in form of attribute model properties, which are loaded from attribute metadata table. The main metadata table eav_attributes contains properties shared by every attribute in Magento’s EAv system. Entity type customer and catalog entity types catalog_category and catalog_product have additional attribute metadata tables: customer_eav_attribute and catalog_eav_attribute, respectively.

The topic of attribute properties deserves a detailed discussion. I will list them one by one and explain their meaning.

• attribute_code – This is, basically, the attribute name. If you need to resolve an attribute code into an id, use the attribute model’s loadByCode() function like in this example.
• attribute_model – This property points to a class that contains the attribute’s model. As it has been said above, some entity types have specific attribute models. Thus, attributes of the catalog entities (catalog_category and catalog_product) have Mage_Catalog_Model_Resource_Eav_Attribute as attribute model, while the customer entity type’s attributes model is Mage_Customer_Model_Attribute. The values for this property are not set in the database. Instead, when loading attribute models, the system will analyze to which entity type the given attribute belongs to, and assign either an entity-type specific model or the default one (Mage_Eav_Model_Entity_Attribute). How does the system know, which entity type has a specific attribute model? This data is stored in the table eav_entity_type in column attribute_model. The EAV config object (Mage_Eav_Model_Config) loads this information while initializing the system’s entity types.
• backend_model – Every entity attribute has a so-called “backend” model assigned to it. This model defines how the attribute data is handled when the entity object is saved or deleted. During these operations the object’s model performs “attribute walking” by calling functions afterLoad(), beforeSave(), afterSave(), beforeDelete() and afterDelete() on the attribute backend model. See Mage_Eav_Model_Entity_Abstract::walkAttributes(). The EAV Attribute property backend_model is a big topic. For its detailed description please refer to the section EAV Attribute Property backend_model.
• backend_type – Backend type indicates in which “skinny” table the attribute’s values are stored. Backend types can be varchar, int, text, decimal, or datetime; and their values are stored in entitytypename_entity_varchar, entitytypename_entity_int, entitytypename_entity_text, entitytypename_entity_decimal, or entitytypename_entity_decimal, respectively (replace entitytypename with customer, catalog_product, or catalog_category). The backend type static is a special case. Attributes of this type store their data in the entity’s main table, even though the data can be int, decimal, or varchar.
• backend_table – This property is closely connected to the attribute’s backend_type, and its values are dependent on what is set in the backend type. That is why the column backend_table in the table eav_attribute is empty. Despite the dynamic generation of backend_table values, you can explicitly set a table name and store it in the database. The database value will have precedence.
• frontend_model – Frontend models point to classes that are responsible for the attribute’s presentation to the user. For a more detailed description of these classes see EAV Attribute Property frontend_model.
• frontend_input – This property defines, what kind of input element is used for the attribute in HTML forms. See more on this property and its role here: EAV attribute Property frontend_input.
• frontend_label – This is a user-friendly name of the attribute. It is displayed next to the attribute input element in admin backend forms or in grid column titles. These values can also be displayed to shop customers. For example, the sorting options in product listing pages are comprised of the frontend_labels of the sortable attributes (the labels are actually used as translation keys; but if no key is found in the localization files – the frontend_label value will be shown to the customer as is).
• frontend_class – The function getClass() of the attribute’s frontend model uses the frontend_class value to assign CSS classes to the attribute’s input element. You can set a CSS class that your custom JavaScript validator can pick up to check the input values against whatever validation rules you want.
• source_model – Source models are mainly used by attributes with frontend_input of type select or multiselect. Source models contain functionality that allows such attributes to have a list of options to choose from. For more details refer to EAV attribute property source_model.
• is_required – When set to true property indicates that this attribute must have a value. The frontend_model will add a required CSS class to the attribute’s HTML input field to enable the client-side JavaScript validation.
• is_user_defined – This property is used to distinguish between system attributes and attributes created by shop users. The former may not be deleted – and that is why the edit form for such attributes doesn’t display the “delete” button. You still can delete system attributes programmatically, but this would be a bad idea. For attributes created by users in the backend, the backend_type property will be implicitly set using the value the user selects for the frontend_input. Also, it is possible to change the “unique” requirement (which mandates that values can not be shared by other products) for user created attributes. Changing this requirement is not allowed for the system attributes.
• default_value – You can provide a default value for the attribute. A default value will come pre-entered into the form input field, or will be used when an entity is created programmatically (e.g. product import), provided the attribute has no explicitly set value.
• is_unique – Setting this attribute to 1 will command the system to check that no two or more entities of the given type share the same value for this attribute. An example could be product SKUs or bar codes.
• note – You can enter a short descriptive text into this field, if you need a tip displayed next to the attribute’s input field in the backend. For example, see the “Meta Description” field in the product edit form.

EAV Attribute Property backend_model

The role of attribute backend model is to process attribute data according to its type whenever the parent entity object is loaded, saved, or deleted. A reference to a backend model class can be set in a database in the table eav_attributes or assigned dynamically when attribute is loaded. In the latter case the system uses the default attribute backend model Mage_Eav_Model_Entity_Attribute_Backend_Default, which extends the abstract class Mage_Eav_Model_Entity_Attribute_Backend_Abstract. Sometimes the attribute’s data type requires functions other than what the default backend model provides. In this case such functionality can be implemented in a custom class extending the abstract backend model. All backend models implement interface Mage_Eav_Model_Entity_Attribute_Backend_Interface. This means they all will have the following minimal set of public functions:

• getTable() – returns the table name (or, more precisely, configuration node pointing to the table name), which stores the attributes data. Think of “skinny” attribute-value tables, for example, customer_entity_varchar, or catalog_product_entity_decimal.
• isStatic() – tells if the attribute is static. Static is the default value for attribute field backend_type. Static attribute values are stored in the main entity table (i.e., catalog_product_entity or customer_entity) and not in the “skinny” EAV attribute-value tables.
• getType() – returns the attribute backend type. They can be varchar, static, int, text, decimal, or datetime. The type defines, in which “skinny” table the EAV entity saves the value of its attributes. The columns of a “skinny” table are: entity_id (references the entity), entity_type_id (references to the ID of the entity’s type: customer, catalog_product etc), attribute_id (pointing to the attribute whose value it is), value (in format corresponding to the attribute’s type: int, decimal, datetime etc). In a case of a multi-store environment where entities can have different values for the same attribute, the store_id column can be used.
• getEntityIdField() – returns the name of a column in EAV attribute tables, where entity_ids are stored. Default name for such column is entity_id; but custom naming is possible – and that is why this function exists.
• setValueId($valueId) – sets the ID of a row containing the entity attribute data.
• getValueId() – returns the ID of a row containing the entity attribute data.
• getEntityValueId($entity) – entity values can be stored in an attribute backend data model instance. They are packed into a protected field as an array, where keys are entity_ids, and values are the IDs of the rows in the skinny table. This function retrieves the data row ID for the given entity.
• setEntityValueId($entity, $valueId) – sets the ID of a row containing the attribute data for the given entity.

The following functions implement custom data manipulation for attribute values of the $object variable. The latter can be a customer, customer address, product, or category object

• afterLoad($object) – processes object attribute data after the object is loaded.
• beforeSave($object) – prepares attribute data before saving the object into the database.
• afterSave($object) – processes attribute data after the object is saved.
• beforeDelete($object) – performs operations on attribute data before the object is deleted.
• afterDelete($object) – processes attribute data (deletes it, in most imaginable cases) after the parent object is deleted.

A quick overview of some of the attribute backend models

There are 60 attribute backend model classes in Magento Community 1.7.0. Not all of them are actively in use. Sales entities, for instance, use flat tables, but retain EAV implementations. The following core modules contain extensions to the abstract attribute backend model:

• Mage_Eav
• Mage_Catalog
• Mage_Customer
• Mage_GiftMessage
• Mage_Sales

A simplified inheritance hierarchy of the backend model classes is as follows:

The models of the Mage_Eav module provide extensions for the common attribute backend model types, such as

• array: by extending the beforeSave() function this model ensures that entity attributes of array type will have their data saved as an imploded string. There is no attribute with such backend type in the Magento core, but should you need one – this is it.
• time_created and time_updated: their respective overrides of the beforeSave() function set the entity’s updated or created time to the current time.
• datetime: formats the date according to the internal rules before saving the attribute data into the database
• increment: fetches a new increment id from an increment model used by the given entity’s type.
• serialized: serializes the attribute data into a string before saving it into the database, and unserializes the data after loading it from the database.
• store: this attribute type is basically an integer store_id. Its backend data model ensures that the attribute’s entity always has a store_id set: before saving the store_id into the database it replaces null data with the current store_id from the request context.

The module Mage_Catalog adds more backend models used by attributes of the catalog_category and catalog_product entity types (under paths catalog/product_attribute_backend and catalog/catalog_attribute_backend).

catalog_product attribute backend models:

• boolean: this type is extended by msrp – ‘manufacturer suggester retail price’.
• customlayoutupdate: extends validation of the attribute value to ensure that it is a valid layout update (this model is also applicable to the attribute custom_layout_update of the catalog_category entity type).
• recurring: is an extension of the serialized attribute type, which adds additional functionality regarding product recurring profiles.
• sku: this type adds additional validation rules for product SKUs (checks if the value does not exceed 64 characters).
• startdate: this extension of the datetime type makes sure that products with special prices also get a proper start date for the sale action (current date time of the product saving moment).
• urlkey: if no URL key has been provided explicitly, a URL key will be generated from the product’s name in the beforeSave() function.

The price backend model types and the product price functionality in general will be discussed in detail in a chapter about catalog products:

• price
• groupprice
• tierprice

The media backend model type attribute is quite complex and also requires a chapter of its own:

• media

catalog_category attribute backend models:

• image: is similar to the product attribute model under the same name: it adds an image upload functionality.
• urlkey: same functionality as in the product URL key attribute model.
• sortby: attributes of this type contain sorting options for category product listings. The extended validate() function ensures that they are valid for this role.

The module Mage_Customer contains a number of its own attribute backend data models:

• billing and shipping: these attributes contain reference IDs to the customer’s default billing and shipping addresses. The afterSave() function of this model checks if the POST request contains addresses marked as either make my default billing address or make my default shipping address, and sets such addresses as values to these attributes.
• boolean: this extension of the abstract data model ensures that attributes of this type will have their empty values replaced with false before saving data into the database.
• password: attributes of type password have an additional validation rule (must match value in the confirmation field). Also, before saving the password into the database its value will be checked for the minimum length (6 characters hard coded minimum length) and hashed (default salt = 2).
• region: this backend model checks is the region (state, province) id that is about to be saved belongs to the country the customer is from.

EAV Attribute Property frontend_model

Another important property of the EAV attribute metadata is frontend_model. This property connects attributes to classes, which define how the attribute is rendered in HTML. Don’t let the word frontend confuse you – it is not about how the attribute is presented to customers in the shop’s “front end”, but about the rendering of the attribute input fields in the administration “back end”. Thus, while the backend_model classes’ work is saving and retrieving the attribute data, frontend_model s are responsible for the data presentation to the user.

Class Mage_Eav_Model_Entity_Attribute_Frontend_Abstract provides a common functionality for attribute frontend models. Some of its methods deserve more attention:

• getClass() – generates a CSS class for the attribute’s input HTML element. If an attribute is required, its input field receives a CSS class required. Other CSS classes can be taken from the attribute’s frontend_class property (stored in the eav_attribute table). Some EAV entities in Magento extend their attribute metadata with a validate_rules property. This property is used to produce additional CSS classes that can be picked up by a JavaScript validator (validate-email, validate-url etc.). Validate rules are stored as serialized associative arrays:

  array(
      'max_text_length'   => 255,
      'min_text_length'   => 1
  )

• getInputRendererClass() – the catalog entities (catalog_category and catalog_product) have an additional attribute property called frontend_input_renderer. It stores configuration references to Magento block classes that extend the HTML output of the attribute’s form input elements. One such example is Mage_Adminhtml_Block_Catalog_Category_Helper_Sortby_Available (look into its function getElementHtml())
• getSelectOptions() – returns you an associated array containing attribute option values and their labels. Very useful when you need to generate a drop down or a multiselect field. Naturally will work only with select or multiselect attributes.

There are 10 classes extending the abstract frontend model. I do not count the frontend model classes in the Mage_Sales module, because I have never encountered them in action. I presume, they are left for backward compatibility, since in the current Magento version (1.7.0) the sales entities use flat tables to store their attribute data. The following diagram show the inheritance relationships of the Magento’s frontend models.

The default frontend model is represented by the class Mage_Eav_Model_Entity_Attribute_Frontend_Default. This class doesn’t contain any overridden functions of properties, but simply references to the implementation in the abstract Mage_Eav_Model_Entity_Attribute_Frontend_Abstract class. Every attribute gets the default frontend model automatically, unless it has an explicit setting in the frontend_model column of the table eav_attribute. In a clean installation of Magento Community 1.7.0 only four attributes have custom defined frontend models:

• customer_entity->dob: Mage_Eav_Model_Entity_Attribute_Frontend_Datetime
• catalog_product_entity->image, catalog_product_entity->small_image, and catalog_product_entity->thumbnail: Mage_Catalog_Model_Product_Attribute_Frontend_Image

EAV attribute property source_model

The property source_model is used by attributes that accept a value from a predefined list of options. Such attributes often have either select or multiselect frontend_input property, although this is not a requirement. Source models implement interface Mage_Eav_Model_Entity_Attribute_Source_Interface. This means that every source model is able to return a list of all possible options for the given attribute, or return an option text. The latter require a bit more explanation. The values of select and multiselect attributes are actually numerical references to option IDs. Attribute options represent a list of values that an attribute can have. All possible options for every attribute in Magento are stored in the table eav_attribute_options. This table, however, contains no values that are meaningful to a human. The option IDs are numerical and reference another table – eav_attribute_option_value. There, finally, you can find text labels that you normally see in the drop-down or multiselect input elements. The diagram below demonstrates the relationships between the skinny EAV tables, where catalog_product entity stores its attribute values, and the attribute option tables. As you can see, the skinny tables are connected to the eav_attribute (Magento’s main EAV attribute definitions table) and to the table eav_attribute_options via foreign key attribute_id. The eav_attribute_option_value table references eav_attribute_option with the option_id foreign key.

Or a more practical example demonstrating option values stored in skinny tables. Display gender attribute values for product with IDs between 29 and 33:

SELECT
    `skinny`.`entity_id` AS 'product_id',
    `main`.`attribute_code`,
    `main`.`attribute_id`,
    `skinny`.`value`,
    `options`.`option_id`,
    `values`.`value`
FROM
    `eav_attribute` AS `main`
        JOIN
    `catalog_product_entity_int` AS `skinny` ON `main`.`attribute_id` = `skinny`.`attribute_id`
        JOIN
    `eav_attribute_option` AS `options` ON `main`.`attribute_id` = `options`.`attribute_id`
    AND `skinny`.`value` = `options`.`option_id`
        JOIN
    `eav_attribute_option_value` AS `values` ON `values`.`option_id` = `options`.`option_id`
WHERE
    `main`.`attribute_code` = 'gender' AND `skinny`.`entity_id` BETWEEN 29 AND 33

This short diversion from the main topic of source models still works as an example of their main function – provide attributes with a value dictionaries. At the top of the source models inheritance hierarchy rests an abstract class called Mage_Eav_Model_Entity_Attribute_Source_Abstract. Unless an attribute has an explicitly set source model, a default model is assigned to it. The default model class is Mage_Eav_Model_Entity_Attribute_Source_Config. If you want to see attributes that use models other than default, run this query in your database:

SELECT
    `attribute_id`,
    `attribute_code`,
    `frontend_input`,
    `frontend_label`,
    `source_model`
FROM
    `eav_attribute`
WHERE
    `source_model` > ''

$dataModelClass = $attribute->getDataModel();
if (!empty($dataModelClass)) {
   if (empty(self::$_dataModels[$dataModelClass])) {
           $dataModel = Mage::getModel($dataModelClass);
           self::$_dataModels[$dataModelClass] = $dataModel;
       } else {
           $dataModel = self::$_dataModels[$dataModelClass];
    }
} else {
    if (empty(self::$_dataModels[$attribute->getFrontendInput()])) {
        $dataModelClass = sprintf('eav/attribute_data_%s', $attribute->getFrontendInput());
        $dataModel      = Mage::getModel($dataModelClass);
        self::$_dataModels[$attribute->getFrontendInput()] = $dataModel;
    } else {
        $dataModel = self::$_dataModels[$attribute->getFrontendInput()];
    }
}

$dataModel->setAttribute($attribute);
$dataModel->setEntity($entity);

return $dataModel;