Category Archives: Magento

Magento Composer

We use Composer for dependency management. Composer enables us to manage the Magento components and their dependencies.
As an integrator, you want to manage each of your Magento core components and third-party components using the Component Manager and System Upgrade.
To do so, you start by creating a Composer project from our metapackage. The metapackage installs each component so it can be centrally managed after installation.

Composer provides you with the following advantages:

Enables you to reuse third-party libraries without bundling them with source code
Component-based architecture with robust dependency management
Manages dependencies to reduce extension conflicts and compatibility issues
Versioned dependencies
Semantic versioning
Supports the PHP Framework Interoperability standard


Magento Sessions

Customer sessions stores data related to customer, checkout session stores data related to quote and order. They are actuall under one session in an array. So firstname in customer/session will be $_SESSION[‘customer’][‘firstname’] and cart items count in checkout/session will be $_SESSION[‘checkout’][‘items_count’]. The reason Magento uses session types separately is because once the order gets placed, the checkout session data information should get flushed which can be easily done by just unsetting $_SESSION[‘checkout’] session variable. So that the session is not cleared, just session data containing checkout information is cleared and rest all the session types are still intact.


Magento Code Pool

codePool is a tag which you have to specify when registering new module in app/etc/modules/Company_Module.xml
There are 3 codePools in Magento: core, community and local, which are resided at app/code/ directory.
Core codePool is used by Magento core team, Community is generally used by 3rd party extensions and Local codePool should be used for in-hour module development and overriding of core and community modules for custom requirement.
So in short, codePool helps Magento to locate module inside app/code/ for processing.


Difference Between EAV And Flat Model

EAV is entity attribute value database model, where data is fully in normalized form. Each column data value is stored in their respective data type table. Example, for a product, product ID is stored in catalog_product_entity_int table, product name in catalog_product_entity_varchar, product price in catalog_product_entity_decimal, product created date in catalog_product_entity_datetime and product description in catalog_product_entity_text table. EAV is complex as it joins 5-6 tables even if you want to get just one product’s details. Columns are called attributes in EAV.

Flat model uses just one table, so it’s not normalized and uses more database space. It clears the EAV overhead, but not good for dynamic requirements where you may have to add more columns in database table in future. It’s good when comes to performance, as it will only require one query to load whole product instead of joining 5-6 tables to get just one product’s details. Columns are called fields in flat model.