Doctrine_manual-1-2-en

Chapter 16: Behaviors 248
Listing
16-25
---
BlogPost:
actAs:
Versionable:
versionColumn: version
className: %CLASS%Version
auditLog: true
columns:
title: string(255)
body: clob
The auditLog option can be used to turn off the audit log history. This is when you want
to maintain a version number but not maintain the data at each version.
Lets check the SQL that is generated by the above models:
Listing
16-26
// test.php
Listing
16-27
// ...
$sql = Doctrine_Core::generateSqlFromArray(array('BlogPost'));
echo $sql[0] . "\n";
echo $sql[1];
The above code would output the following SQL query:
CREATE TABLE blog_post_version (id BIGINT,
title VARCHAR(255),
body LONGTEXT,
version BIGINT,
PRIMARY KEY(id,
version)) ENGINE = INNODB
CREATE TABLE blog_post (id BIGINT AUTO_INCREMENT,
title VARCHAR(255),
body LONGTEXT,
version BIGINT,
PRIMARY KEY(id)) ENGINE = INNODB
ALTER TABLE blog_post_version ADD FOREIGN KEY (id) REFERENCES
blog_post(id) ON UPDATE CASCADE ON DELETE CASCADE
Notice how we have 2 additional statements we probably didn't expect to see. The behavior
automatically created a blog_post_version table and related it to blog_post.
Listing
16-28
Now when we insert or update a BlogPost the version table will store all the old versions of
the record and allow you to revert back at anytime. When you instantiate a BlogPost for the
first time this is what is happening internally:
• It creates a class called BlogPostVersion on-the-fly, the table this record is
pointing at is blog_post_version
• Everytime a BlogPost object is deleted / updated the previous version is stored into
blog_post_version
• Everytime a BlogPost object is updated its version number is increased.
Now lets play around with the BlogPost model:
$blogPost = new BlogPost();
$blogPost->title = 'Test blog post';
----------------- Brought to you by