It is no secret that CakePHP was born to implement the ideas of Ruby on Rails to the world of PHP – wonderful ideas, indeed, and I think we should pay tribute to the guys at 37signals.

But what CakePHP still lacks, in my opinion, is pure and complete DB abstraction. It is true that most recent versions of Cake ( v.2 RC3 as of now ) have done a lot in that area – the framework is now strongly decoupled from MySQL, although I personally have never heard of study cases that use Oracle, for example.

To the point – in a multi-developer environment it is critical to have a versioning control system ( you know you should be using git, right? ) and a database ‘versioning’ system – that is where Rails is much more powerful than CakePHP – it has database migrations.

Some migrations’ background

If you know what migrations are – skip that part and go directly to the next one. Otherwise – here is a simple explanation: they are related to the database like git ( or svn or cvs ) is related to the source. They simple provide a way to go back or forth to a previous or succeeding state ( or version ) of the database schema. The features of migrations are:

• They are DB agnostic – this means that they are not affected by the type of the DB server you’re using and help you in deploying your apps on different environments
• They help you with your agile development – you can put info in and out without affecting the rest of the project
• They provide you with a quick way to revert back to a previous state of the DB in case something went wrong
• DB migrations can save your life if you work in a team

To illustrate the all said, I have a simple example: You create a blog ( of course a blog – that’s probably the most often used example in the world ). Let’s split the development into three simple parts – development of blog posts CRUD; adding ACL; adding Comments to posts and.. that’s it – we want a simple example, after all.

So, first – blog posts Create, Read, Update, Delete. You begin by creating your DB schema. You need a simple posts’ table with a few fields – id, title, body, created. Then you write your PHP code, of course ( out of scope here ).

But one beautiful day you decide more than one person should be able to add posts and modify their own posts only – that’s when you read about Access Control Lists. Now you need a few more tables – users, aros, acos, acl and you need to add a field to the posts’ table ( user_id, for example ). Our small blog is getting just a bit more complex.

Finally, you want comments! But you have no time and ask your cousin for a favor ( he is a good dev, after all ). He adds another table for that. And then decides only registered users ( who cannot write new posts ) can add comments. And, of course, writes some more code. And inserts some more data in the db.

You ( and your cousin ) have went through 3 distinctive phases of agile development. You have, of course, used git ( oh, well, maybe svn or cvs ) to keep track of your code and make sure everything is ok and that you can revert back to a previous, stable version, if anything goes wrong. But then, one day – something really goes wrong. And you need to revert from state 3 to state 2 – i.e. remove the comments. But … your cousin is

• out of town
• mad at you because you behaved badly on his last birthday party
• has no idea what he did for you so many months ago

No problem – you use your source versioning system and do the reversal. But.. something is still wrong – your database stays unchanged. What did you add from v2 to v3? Did you remove something? And you know nothing about Database Server X – can you write the SQLs to revert the schema?

That is where DB migrations come in and save your life. Well, maybe not that important with your blog but imagine 100+ development iterations and 10+ developers working simultaneously on your project and maintaining it on many different platforms – this can turn into a small nightmare.

Joel Moss and his migrations

In his article at the Bakery Joel Moss describes how to use his CakePHP migrations shell. Although that project was my inspiration and I highly respect his work, his approach has several drawbacks:

• it uses PEAR – I don’t like it – that’s why I use CakePHP. I do not find necessary to explain this – I guess it is highly subjective.
• it is non-modular – you cannot use it to deploy applications – it is just a shell with no ‘core’
• it cannot make a snapshot of your already existing schema – you haven’t used migrations yet? That’s something you will need.
• it cannot merge your tables – that can be crucial when you already have different versions of the schema on different platforms and you just want them all to be standardized

So, I proudly present you with

My CakePHP Yaml Migrations and Fixtures

The idea was born when Eelco and I started working on PagebakeryCMS some time ago and was later further developed when we decided we needed a standardized CakePHP App Installer. You can get a copy of the project and follow it, too. What I personally find useful in it:

• no external libraries – only the SPYC class used to parse YAML files ( that is authored by Chris Wanstrath )
• can easily complement your source versioning system – use it for team collaboration
• can be used for DB abstraction installers – when deploying your applications on different platforms you don’t want to modify your SQLs – and the project is DB agnostic. The package also has fixtures ( well, the terms is not used correctly – this is for adding initial data to your database )
• can be used to standardize already installed applications on different platforms
• can help you make your apps DB agnostic by generating a YAML structure of your schema from where you can go on with the agnostic aproach

How it works

Just put all files in your CakePHP vendors folder.

If you want to use the API only, simply include the classes in your code

App::Import('vendor', 'migrations' )

and/or

App::Import('vendor', 'fixtures' )

And then, for example

$migrations = new Migrations();
$migrations->load('comments.yml');
$migrations->up();

For more usages – dig into the code a bit

If you have ever tried to develop a robust ajax application, you have probably reached a point where you want the client to be notified about a change on the server in “real time”. The most simple example – you need to create a chat application and want the client to instantly receive new messages upon their arrival on the server. And, if you like me, are not a fan of Flash ( which may be one of your major flaws ) and want to achieve this using only ajax techniques, you have found out that is not that simple.

There is no real channel between the server and the client

In that case you have no real permament connection between the server and the client and there is no real way of “triggering” events or sending data from the server to the client in any traditional way. Moreover, ajax does not support the client “listening” and waiting for a server’s call ( well, that’s a client after all ). You googled for some time, asked some fellow developers and almost all you could find was – “Just use javascript’s (notorious) setTimeout() or setInterval() function to repeatedly poll the server and check whether there is new data for the client”.

Like, for example ( using jQuery ) :

function read(){
  jQuery.ajax( {
    'url'     : 'chat/read/',
    'cache'   : false,
    'dataType': 'json',
    'success' : function(messages){
      //if there are new messages - write them on the wall
      if( messages ){
	//write messages to the chat wall
      }
    } );
  }
}
 
setTimeout( function(){ read() }, 2000 );

( I will not show any server-side code examples as they are simple enough – the method being /chat/read/ would just read from the database and return new records. Moreover, what we have here is not what we’re trying to achieve – the example here is for descriptive purposes only. )

Is that what we call highly-responsive, flexible applications, you’d ask? No. This technique has several drawbacks:

• it sends http requests from the client to the server and gets response ( most of the time empty ones ) on every X number of seconds. X usually is a far too small number and that can translate into way too much wasted bandwidth, if we are talking about a high-traffic website and if we need that polling done for multiple actions
• it can eventually make the client hang-up as most modern browsers ( except for Chrome – or at least – what Chrome pleads ) don’t have smart javascript garbage collection and all those requests can be quite costly.
• it is not really highly-responsive – it has a lag of 2 seconds which may be enough to make the users nervous
• this just doesn’t feel like the right way of doing things

Comet

Well, I need to be honest – the Comet technique ( also known as long-polling ) seems like nothing new but I personally was not aware of it’s power till recently ( Eelco pointed it to me ). But you will be amazed how many open- and closed-source projects have no idea that it is out there and do not try to use it. And it is simple – you make a request to the server, it gets it and just… waits. Waits till there is meaningful data to be returned or returns something less useful ( like null ), if the request is about to timeout. On a standard apache configuration that would mean 5 minutes – you can make just one single request on every 5 minutes, not on every 2 seconds ( which a traditional ajax app would do ). That is 150+ times less requests, less bandwidth, less javascript functions’ calls and the application would feel much more responsive.

There is, however, a small side note to mention…

PHP Sessions are not keen on long-polling

And, if you hadn’t read this post, you’d have had some hard time finding this out. It is just that in every normal application, you can be 97% sure you will be using sessions. And in most of the time, you will rely on the built-in php sessions’ handler. So far, so good. But the small problem is that you cannot simultaneously be running different scripts ( or more than one instantiation of a script ) which use one and the same user session ( that, again, was a discovery by Mr. Pagebaker ). PHP will just queue all subsequent requests which try to interact with that session, until the first one has been closed. Well, that is not much of an asynchroneous technique either then. Getting back to our chat application – if you want to long-poll the server and wait for new messages ( what we will call read() ) and simultaneously send new messages to the server ( write() ), the application will not write() until the read() request has finished ( which we have set to 5 mins, if in the worst case there is no new data to be received ) – that is absolutely not what we need.

Frameworks to the rescue

But, as all self-respectful developers, you have adopted a php framework which provides an alternative to the native php sessions’ handler – be it file, database or any other geeky approach. I’d prefer CakePHP where it is simple – just open your /app/config/core.php and find

Configure::write('Session.save', 'php');

change that to

Configure::write('Session.save', 'database');

and uncomment the few lines below that line with respective data.

So, now let’s see what we have:

Our client-side script ( jQuery again ):

function read(){
  jQuery.ajax({
    'url'     : '/chat/read/',
    'cache'   : false,
    'dataType': 'json',
    'success' : function(messages){
      if( messages.length ){
	//write to chat wall
      }
      read();
    }
  });
}

It is important to notice that even though I have not shown the write() function, you should use jQuery’s Ajax Queue Plugin, so that our write requests are kept in good order. That is not needed when we read() as no subsequent read() requests will be fired before the first one has ended.

And, our cakephp chat controller method:

public function read(){
  $lastMessage_id = $this->Session->read('Conversation.lastMessage_id');
  if( $lastMessage_id === null ){
    echo $this->Json->encode( array() );
    $this->Session->write( 'Conversation.lastMessage_id', 0 );
    exit(0);
  }
  $now = time();
  $timeout = 300;
  while(!connection_aborted()){
    $messages = $this->Conversation->read( $lastMessage_id );
    if( !empty( $messages ) ){
      $this->Session->write( 'Conversation.lastMessage_id', $messages[ count( $messages ) - 1]['Message']['id'] );
      echo $this->Json->encode( $messages );
      exit(0);
    }
    elseif( time() > $now + $timeout ){
      echo $this->Json->еncode( array() );
      exit(0);
    }
    sleep(1);
  }
}

In short – we get the last message id from the user session then use it to fetch newer records from the model. If there are none and the user hasn’t left our webpage, we start looking for new messages once again and so on. We also keep track on the time we have spent so far in that iteration – we don’t want an ugly timeout, that is why we just send an empty response, if we have reached a critical level ( $timeout = 300 in that case ).

For simplicity, I do not use views in that example but it is highly recommended that you avoid using the JSON component and use views instead ( who knows, you might need a different format in the future ).

Notice the sleep(1) line – we don’t want our CPU to burn out after a few hours of work, so some time for rest is highly recommended. You may, of course, use smaller intervals but at your own risk.

That is it for now – feel free to comment and thanks for reading