There are a few [other methods] that can be really useful for performing relatively complex tasks with a minimal amount of code. That's exactly the case with the "__destruct()" method, which will be called automatically by the PHP engine before destroying an instance of a particular class at the end of a script.

They update their example class with a new __destruct method that takes the user information inserted previously, serializes it and drops it into the current session.

You must be doing something right when you can send PHP into a tail spin. That or the code you're trying to do is just evil. Turns out __destruct() and __call() don't play well together in 5.2.4 if, and only if, you create an instance of an object without assigning it.

The official (and verified) bug over on the bugs.php.net site gets into more detail on it including a code block that illustrates the point as simply as possible.

In the example I blogged about, __destruct() actually wants to catch any exceptions so it can create meaningful output based on the Exceptions that were generated. In that case, __destruct() would have returned peacefully. [...] At any rate, my take on that would be that would still be that if __destruct() is finished and an exception is still present, then there's an error. Otherwise, how would you handle things such as PDOExceptions thrown during DB clean-up?

Migrations are a wonderful technique to keep your database in sync with your code. When working on a project as a team, migrations can save your life. Please join me and get a quick introduction to migrations in CakePHP and become a happier coder.

He starts by explaining what migrations are (yml files that contain database construction/destruction information), how to execute them in your application, and how to construct your own.