Magento Models and ORM Basics

The implementation of a “Models Tier” is a huge part of any MVC framework. It represents the data of your application, and most applications are useless without data. Magento Models play an even bigger role, as they typically contain the “Business Logic” that’s often (right or wrong) relegated to the Controller or Helper methods in other PHP MVC frameworks.

The following is part of a longer series about Magento aimed at developers familiar with PHP MVC development. While each article can be read stand alone, each article does build on concepts covered in previous articles. If you’re confused, be sure to catch up on the older stuff first.

Traditional PHP MVC Models

If the definition of MVC is somewhat fuzzy, the definition of a Model is even fuzzier. Prior to the wide adoption of the MVC pattern by PHP developers, data access was usually raw SQL statements and/or a SQL abstraction layer (such as AdoDB). Developers would write queries and not think too much about that objects they were modeling.

In 2009 raw SQL is mostly frowned upon, but many PHP frameworks are still SQL centric. Models will be objects that provide some layer of abstraction, but behind the scenes developers are still writing SQL and/or calling SQL like abstraction methods to read and write-down their data.

Other frameworks eschew SQL and take the Object Relational Mapping (ORM) approach. Here, a developer is dealing strictly with Objects. Properties are set, and when a save method is called on the Object, the data is automatically written to the database. Some ORMs will attempt to divine object properties from the database, others require the user to specify them in some way, (usually in an abstract data language such as YAML). One of the most famous and popular implementations of this approach is ActiveRecord.

This definition of ORM should suffice for now, but like everything Computer Science these days, the strict definition of ORM has blurred over the years. It’s beyond the scope of this article to settle that dispute, but suffice it say I’m generalizing a bit and probably asking to be jumped by a couple of Java developers when I leave the house.

Magento Models

It should be no surprise that Magento takes the ORM approach. While the Zend Framework SQL abstractions are available, most of your data access will be via the built in Magento Models, and Models you build yourself. It should also come as no surprise that Magento has a highly flexible, highly abstract, sometimes confusing concept of what a Model is.

Anatomy of a Magento Model

Most Magento Models can categorized in one of two way. There’s a basic, ActiveRecord-like/one-object-one-table Model, and there’s also an Entity Attribute Value (EAV) Model. There’s also Model Collections. Collections are PHP objects used to hold a number of individual Magento Model instances. The Varien team has implemented the PHP Standard Library interfaces of IteratorAggregate and Countable to allow each Model type to have it’s own collection type. If you’re not familiar with the PHP Standard Library, think of Model Collections as arrays that also have methods attached.

Magento Models don’t contain any code for connecting to the database. Instead, each Model has two modelResouces, (one read, one write), that are used to communicate with the database server (via read and write adapter objects). By decoupling the logical Model and the code that talks to the database, it’s theoretically possible to write new resource classes for a different database platform while keeping your Models themselves untouched.

Creating a Basic Model

To begin, we’re going to create a basic Magento Model. PHP MVC tradition insists we model a weblog post. The steps we’ll need to take are

1. Create a new “Weblog” module

2. Create a database table for our Model

3. Add Model information to the config for a Model named Blogpost

4. Add Model Resource information to the config for the Blogpost Model

5. Add A Read Adapter to the config for the Blogpost Model

6. Add A Write Adapter to the config for the Blogpost Model

7. Add a PHP class file for the Blogpost Model

8. Add a PHP class file for the Blogpost Model

9. Instantiate the Model

Create a Weblog Module

You should be an old hat at creating empty modules at this point, so I’ll skip the details and assume you can create an empty module named Weblog. After you’ve done that, we’ll setup a route for an index Action Controller with an action named “testModel”. As always, the following examples assume a Package Name of “Alanstormdotcom”.

In Alanstormdotcom/Weblog/etc/config.xml, setup the following route

<frontend>
    <routers>
        <weblog>
            <use>standard</use>
            <args>
                <module>Alanstormdotcom_Weblog</module>
                <frontName>weblog</frontName>
            </args>
        </weblog>
    </routers>
</frontend>       

And then add the following Action Controller in

class Alanstormdotcom_Weblog_IndexController extends Mage_Core_Controller_Front_Action {    
    public function testModelAction() {
        echo 'Setup!';
    }
}

at Alanstormdotcom/Weblog/controllers/IndexController.php. Clear your Magento cache and load the following URL to ensure everything’s been setup correctly.

http://example.com/weblog/index/testModel

You should see the word “Setup” on a white background.

Creating the Database Table

Magento has a system for automatically creating and changing your database schemas, but for the time being we’ll just manually create a table for our Model.

Using the command-line or your favorite MySQL GUI application, create a table with the following schema

CREATE TABLE `blog_posts` (
  `blogpost_id` int(11) NOT NULL auto_increment,
  `title` text,
  `post` text,
  `date` datetime default NULL,
  `timestamp` timestamp NOT NULL default CURRENT_TIMESTAMP,
  PRIMARY KEY  (`blogpost_id`)
)

And then populate it with some data

INSERT INTO `blog_posts` VALUES (1,'My New Title','This is a blog post','2009-07-01 00:00:00','2009-07-02 23:12:30');

The Global Config and Creating The Model

There are four individual things we need to setup for a Model in our config.

1. Enabling Models in our Module

2. Enabling Model Resources in our Module

3. Add an “entity” to our Model Resource. For simple Models, this is the name of the table

4. Specifying a Read Adapter for our specific Model Resource

5. Specifying a Write Adapter for our specific Model Resource

When you instantiate a Model in Magento, you make a call like this

$model = Mage::getModel('weblog/blogpost');

The first part of the URI you pass into get Model is the Model Group Name. Because of the way Magento __autoloads classes, this also has to be the (lowercase) name of your module. The second part of the URI is the lowercase version of your Model name.

So, let’s add the following XML to our module’s config.xml.

<global>
    <!-- ... -->
    <models>
        <weblog>
            <class>Alanstormdotcom_Weblog_Model</class>
            <!-- 
            need to create our own resource, can't just
            use core_mysql4
            -->
            <resourceModel>weblog_mysql4</resourceModel>
        </weblog>    
    </models>
    <!-- ... -->
</global>

The outer <weblog /> tag is your Group Name, which should match your module name. <class /> is the BASE name all Models in the weblog group will have. The <resourceModel /> tag indicates which Resource Model that weblog group Models should use. There’s more on this below, but for now be content to know it’s your Group Name, followed by a the literal string “mysql4”.

So, we’re not done yet, but let’s see what happens if we clear our Magento cache and attempt to instantiate a blogpost Model. In your testModelAction method, use the following code

    public function testModelAction() {
        $blogpost = Mage::getModel('weblog/blogpost');
        echo get_class($blogpost);
    }

and reload your page. You should see an exception that looks something like this (be sure you’ve turned on developer mode).

include(Alanstormdotcom/Weblog/Model/Blogpost.php) [function.include]: failed to open stream: No such file or directory

By attempting to retrieve a weblog/blogpost Model, you told Magento to instantiate a class with the name

Alanstormdotcom_Weblog_Model_Blogpost

Magento is trying to __autoload include this Model, but can’t find the file. Let’s create it! Create the following class at the following location

File: app/code/local/Alanstormdotcom/Weblog/Model/Blogpost.php


class Alanstormdotcom_Weblog_Model_Blogpost extends Mage_Core_Model_Abstract 
{
    protected function _construct()
    {
        $this->_init('weblog/blogpost');
    }    
}

Reload your page, and the exception should be replaced with the name of your class.

All basic Models should extend the Mage_Core_Model_Abstract class. This abstract class forces you to implement a single method named _construct (NOTE: this is not PHP’s constructor __consutrct). This method should call the class’s _init method with the same identifying URI you’ll be using in the Mage::getModel method call.

The Global Config and Resources

So, we’ve setup our Model. Next, we need to setup our Model Resource. Model Resources contain the code that actually talks to our database. In the last section, we included the following in our config.

<resourceModel>weblog_mysql4</resourceModel>

The value in <resourceModel /> will be used to instantiate a Model Resource class. Although you’ll never need to call it yourself, when any Model in the weblog group needs to talk to the database, Magento will make the following method call to get the Model resource

Mage::getResourceModel('weblog/blogpost');

Again, weblog is the Group Name, and blogpost is the Model. The Mage::getResourceModel method will use the weblog/blogpost URI to inspect the global config and pull out the value in <resourceModel> (in this case, weblog_mysql4). Then, a model class will be instantiated with the following URI

weblog_mysql4/blogpost

So, if you followed that all the way, what this means is, resource models are configured in the same section of the XML config as normal Models. This can be confusing to newcomers and old-hands alike.

So, with that in mind, let’s configure our resource. In our <models> section add

<global>
    <!-- ... -->
    <models>        
        <!-- ... -->
        <weblog_mysql4>
            <class>Alanstormdotcom_Weblog_Model_Mysql4</class>                
        </weblog_mysql4>
    </models>
</global>

You’re adding the <weblog_mysql4 /> tag, which is the value of the <resourceModel /> tag you just setup. The value of <class /> is the base name that all your resource modes will have, and should be named with the following format

Packagename_Modulename_Model_Mysql4

So, we have a configured resource, let’s try loading up some Model data. Change your action to look like the following

public function testModelAction() {
    $params = $this->getRequest()->getParams();
    $blogpost = Mage::getModel('weblog/blogpost');
    echo("Loading the blogpost with an ID of ".$params['id']);
    $blogpost->load($params['id']);        
    $data = $blogpost->getData();
    var_dump($data);    
}

And then load the following URL in your browser (after clearing your Magento cache)

http://example.com/weblog/index/testModel/id/1

You should see an exception something like the following

Warning: include(Alanstormdotcom/Weblog/Model/Mysql4/Blogpost.php) [function.include]: failed to open stream: No such file ....

As you’ve likely intuited, we need to add a resource class for our Model. Every Model has its own resource class. Add the following class at at the following location

File: app/code/local/Alanstormdotcom/Weblog/Model/Mysql4/Blogpost.php

class Alanstormdotcom_Weblog_Model_Mysql4_Blogpost extends Mage_Core_Model_Mysql4_Abstract{
    protected function _construct()
    {
        $this->_init('weblog/blogpost', 'blogpost_id');
    }    
}

Again, the first parameter of the init method is the URL used to identify the Model. The second parameter is the database field that uniquely identifies any particular column. In most cases, this should be the primary key. Clear your cache, reload, and you should see

Loading the blogpost with an ID of 1

array
empty

So, we’ve gotten things to the point where there’s no exception, but we’re still not reading from the database. What gives?

Each Model group has a read adapter (for reading from the database) and a write adapter (for updating the database). Magento allows a Model to use the default adapter, or for developers to write their own. Either way, we need tell Magento about it. We’ll be adding a new tag section named <resources /> to the <global /> section of our module config.

<global>
    <!-- ... -->
    <resources>
        <weblog_write>
            <connection>
                <use>core_write</use>
            </connection>
        </weblog_write>
        <weblog_read>
            <connection>
                <use>core_read</use>
            </connection>
        </weblog_read>        
    </resources>        
</global>

We’re adding two sub-sections to <resources />. One for writing, and one for reading. The tag names (<weblog_write /> and <weblog_read />) are based on the Group Name we defined above (“weblog”).

OK, surely with our adapter’s in place we’re ready. Let’s clear our cache, reload the the page, and …

Can't retrieve entity config: weblog/blogpost

Another exception! When we use the Model URI weblog/blogpost, we’re telling Magento we want the Model Group weblog, and the blogpost Entity. In the context of simple Models that extend Mage_Core_Model_Mysql4_Abstract, an entity corresponds to a table. In this case, the table named blog_post that we created above. Let’s add that entity to our XML config.

    <models>
        <!-- ... --->
        <weblog_mysql4>
            <class>Alanstormdotcom_Weblog_Model_Mysql4</class>
            <entities>
                <blogpost>
                    <table>blog_posts</table>
                </blogpost>
            </entities>                    
        </weblog_mysql4>
    </models>

We’ve added a new <entities /> section to the resource Model section of our config. This, in turn, has a section named after our entity (<blogpost />) that specifies the name of the database table we want to use for this Model.

Clear your Magento cache, cross your fingers, reload the page and …

Loading the blogpost with an ID of 2

Loading the blogpost with an ID of 1

array
  'blogpost_id' => string '1' (length=1)
  'title' => string 'My New Title' (length=12)
  'post' => string 'This is a blog post' (length=19)
  'date' => string '2009-07-01 00:00:00' (length=19)
  'timestamp' => string '2009-07-02 16:12:30' (length=19)

Eureka! We’ve managed to extract our data and, more importantly, completely configure a Magento Model.

Basic Model Operations

All Magento Models inherit from the the Varien_Object class. This class is part of the Magento system library and not part of any Magento core module. You can find this object at

lib/Varien/Object.php

Magento Models store their data in a protected _data property. The Varian_Object class gives us several methods we can use to extract this data. You’ve already seen getData, which will return an array of key/value pairs. This method can also be passed a string key to get a specific field.

$model->getData();
$model->getData('title');

There’s also a getOrigData method, which will return the Model data as it was when the object was initially populated, (working with the protected _origData method).

$model->getOrigData();
$model->getOrigData('title');

The Varien_Object also implements some special methods via PHP’s magic __call method. You can get, set, unset, or check for the existence of any property using a method that begins with the word get, set, unset or has and is followed by the camel cased name of a property.

$model->getBlogpostId();
$model->setBlogpostId(25);
$model->unsetBlogpostId();
if($model->hasBlogpostId()){...}

For this reason, you’ll want to name all your database columns with lower case characters and use underscores to separate characters. More recent version of Magento have depreciated this syntax in favor of implementing the PHP ArrayAccess interface

$id = $model['blogpost_id'];
$model['blogpost_id'] = 25;
 //etc...

That said, you’re likely to see both techniques used throughout the Magento code base, as well as third party extensions.

Update: June 1, 2011: It looks like there’s a bug with the ArrayAccess method. Compare Varien_Object‘s setData method (used with the magic methods)

public function setData($key, $value=null)
{
    $this->_hasDataChanges = true;
    if(is_array($key)) {
        $this->_data = $key;
    } else {
        $this->_data[$key] = $value;
    }
    return $this;
}

and offsetSet (the method that implements ArrayAccess)

public function offsetSet($offset, $value)
{
    $this->_data[$offset] = $value;
}

In setData, the _hasDataChanges property is set. If this flag is false, Magento will skip running its database update code. This is likely a performance optimization that failed to take ArrayAccess into account. Probably a good sign that most core team members prefer the magic methods. 🙂

If you’re creating custom Models, you could work around this by overriding offsetSet, and then calling its parent

public function offsetSet($offset, $value)
{
    $this->_hasDataChanges = true;
    return parent::offsetSet($offset, $value);
}

Thanks to Josh from the comments for pointing this out. Also, as long as I’m here, my comments about the magic getters and setters being deprecated were incorrect. I had based that on the following code, also from Varien_Object

/**
 * Attribute getter (deprecated)
 *
 * @param string $var
 * @return mixed
 */

public function __get($var)
{
    $var = $this->_underscore($var);
    return $this->getData($var);
}

/**
 * Attribute setter (deprecated)
 *
 * @param string $var
 * @param mixed $value
 */
public function __set($var, $value)
{
    $var = $this->_underscore($var);
    $this->setData($var, $value);
}

It’s only the use of __get and __set that’s been deprecated. Magento implements all magic functionality in the __call method.

CRUD, the Magento Way

Magento Models support the basic Create, Read, Update, and Delete functionality of CRUD with load, save, and delete methods. You’ve already seen the load method in action. When passed a single parameter, the load method will return a record whose id field (set in the Model’s resource) matches the passed in value.

$blogpost->load(1);

The save method will allow you to both INSERT a new Model into the database, or UPDATE an existing one. Add the following method to your Controller

public function createNewPostAction() {
    $blogpost = Mage::getModel('weblog/blogpost');
    $blogpost->setTitle('Code Post!');
    $blogpost->setPost('This post was created from code!');
    $blogpost->save();
    echo 'post created';
}

and then execute your Controller Action by loading the following URL

http://example.com/weblog/index/createNewPost

You should now see an additional saved post in you database table. Next, try the following to edit your post

public function editFirstPostAction() {
    $blogpost = Mage::getModel('weblog/blogpost');
    $blogpost->load(1);
    $blogpost->setTitle("The First post!");
    $blogpost->save();
    echo 'post edited';
}

And finally, you can delete your post using very similar syntax.

public function deleteFirstPostAction() {
    $blogpost = Mage::getModel('weblog/blogpost');
    $blogpost->load(1);
    $blogpost->delete();
    echo 'post removed';
}

Model Collections

So, having a single Model is useful, but sometimes we want to grab list of Models. Rather than returning a simple array of Models, each Magento Model type has a unique collection object associated with it. These objects implement the PHP IteratorAggregate and Countable interfaces, which means they can be passed to the count function, and used in for each constructs.

We’ll cover Collections in full in a later article, but for now let’s look at basic setup and usage. Add the following action method to your Controller, and load it in your browser.

public function showAllBlogPostsAction() {
    $posts = Mage::getModel('weblog/blogpost')->getCollection();
    foreach($posts as $blog_post){
        echo '<h3>'.$blog_post->getTitle().'</h3>';
        echo nl2br($blog_post->getPost());
    }
}

Load the action URL,

http://example.com/weblog/index/showAllBlogPosts

and you should see a (by now) familiar exception.

Warning: include(Alanstormdotcom/Weblog/Model/Mysql4/Blogpost/Collection.php) [function.include]: failed to open stream

You’re not surprised, are you? We need to add a PHP class file that defines our Blogpost collection. Every Model has a protected property named _resourceCollectionName that contains a URI that’s used to identify our collection.

  protected '_resourceCollectionName' => string 'weblog/blogpost_collection'

By default, this is the same URI that’s used to identify our Resource Model, with the string “_collection” appended to the end. Magento considers Collections part of the Resource, so this URI is converted into the class name

Alanstorm_Weblog_Model_Mysql4_Blogpost_Collection

Add the following PHP class at the following location

File: app/code/local/Alanstormdotcom/Weblog/Model/Mysql4/Blogpost/Collection.php

class Alanstormdotcom_Weblog_Model_Mysql4_Blogpost_Collection extends Mage_Core_Model_Mysql4_Collection_Abstract {
    protected function _construct()
    {
            $this->_init('weblog/blogpost');
    }
}

Just as with our other classes, we need to init our Collection with the Model URI. (weblog/blogpost). Rerun your Controller Action, and you should see your post information.

Wrapup and a Quick Note on Core Magento Models

Congratulations, you’ve created and configured you first Magento Model. In a later article we’ll take a look at Magento’s Entity Attribute Value Models (EAV), which expand on what we’ve learned here.

Also, there’s a little fib we had to tell you earlier. In this article we indicated that all basic Magento Models inherit from Mage_Core_Model_Abstract. This isn’t 100% true. This Abstract method hasn’t existed for Magento’s entire life, and there are still many Models in the system that inherit directly from Varien_Object. While this shouldn’t affect any Models you create, it is something you’ll want to be aware of while working with Magento code.

Like this article? Then you’ll love Commerce Bug, the must have debugging extension for anyone using Magento. Whether you’re just starting out or you’re a seasoned pro, Commerce Bug will save you and your team hours everyday. Grab a copy and start working with Magento instead of against it.