Thread

The result::save() function you have there is an extremely small and bare-bones implementation of Active Record.
(I think, because you may have a hidden mapper, right? 😛)

Yes, that save() was the only thing that I considered possibly needed and it just calls the main DB object instance and passes itself. For my QAL I wanted something small and lightweight that used PDO and yet supported the db->select() db->where() styled format of CodeIgniter. I’ll be releasing it soon after I finish some stuff.

ORM is simply a definition of how we handle data in applications. There’s not exactly a line between “is ORM” and “is not ORM.”

When you iterate over a result object, each object relates to a record in the database. ORM is happening here:

$query = $this->db->get('person');
foreach ($query->result() as $person)
{
   echo $person->name; // OMG, we just ORMed.
}

Bacically, you have added a save() method to what would otherwise just be a stdClass object. This gives the ORM more features, and arguably a stronger relationship/better API with the records of the database. You could say it’s “better” ORM. Likewise, ORM that has methods for linking related records (has one, has many, etc) can be called a “better” ORM.

If you were going to assign a better name to what the database class in CI does, you could say it is Active Query, perhaps. The benefit is the query is represented by an object, not a string

echo $person->name; // OMG, we just ORMed.

I’m putting this on the back of that shirt.

I’m also working on a new QAL, and I must say that I really like to be able to throw away PHP 4.
It is much easier to work with subqueries then.

The QAL I build is for my new ORM / Database abstraction, and from the speed tests it is twice as fast as IgnitedQuery (the QAL of IgnitedRecord) and takes only a third of its size, so I’m happy 😊
It differs from CI’s AR though - think of it like a feature-dense merge of CI’s AR and Zend_Db_Select.

Going to be released as an alpha (missing ORM) as soon as I have the QAL and the Table abstraction (creating, deleting and altering tables) done.

@Colin Williams:

You’re right, there are many ways of creating an ORM.

Usually you say that it is an ORM if it does some things automatically, but the combination of CI’s AR and StdClass objects can also be considered as a very very *very* basic ORM.
The only thing that I can complain about in your example is that $this->db->update(‘users’, $data_object) needs a where string to accurately update the correct row.
So it does not directly map to a row, you have to specify that yourself.

But in a very loose meaning that can be considered an ORM.

Certainly, m4rw3r. Although, I also don’t think you need to tie the methods directly to the mapped objects in order to have a strong relationship. The model can facilitate the mapping.

$post = $this->blog_model->get(1);
$post->title = $this->input->post($title);
$this->blog_model->save($post); // vs. $post->save()

Your example of using Db::update() isn’t so relevant because that’s just what goes on behind the scenes. Even $post->save() is going to run an update()-like function somewhere in the background.

That is the Data Mapper pattern you just demonstrated

I was just pointing out that a real ORM would have added “WHERE id = ?” automatically.

Right on.

Although, I also don’t think you need to tie the methods directly to the mapped objects in order to have a strong relationship. The model can facilitate the mapping.

Now this seems like it might change things. Given that the CI Database is meant to be extended by models we build for our site - does this mean that CodeIgniters Active Record class can become a true ORM once we build a model using it? Thereby validating it’s claim?

class blog_model {
    function __constuct($db) {
        $this->db = $db;
    }
    
    
    function find_user($id) {
        return $this->db->get_where('users', 'id = '. $id);
    }
}

....

$user = $this->blog_model->find_user($id);

I have a model template I always use that comes with get() save() and delete() methods (among others). So I use it as a starting point, update some properties, and I’m ready to roll with the syntax I laid out above.

I started to write a tutorial around this idea but it’s sitting in Google Docs half-complete right now. I have a lot of tutorials in that state 😊

Mine are sitting in gmail drafts.

I had a hunch I wasn’t the only one.

I had a hunch I wasn’t the only one.

I implemented mine in a recent project but still looking into implementing the Automodel.

@Xeoncross:

The thing is that the model using CI’s ActiveRecord usually ends up with the Data Mapper pattern (or a very similar approach) because the model is the sole proxy for all database interaction.

As I’ve described earlier, that does not warrant the name Active Record as it does not make it easier to create the Active Record pattern, instead the Data Mapper pattern is easier to make.
Another thing hampering the development of an Active Record ORM using CI’s AR is that CI’s AR only has one single instance per database connection, making interference more likely.

Active Record == ORM
Data Mapper == ORM
Active Record !== Data Mapper