UPDATE [table] SET [field] = 1 XOR [field] WHERE [conditions]

So how do we fix this?

The Controller

In Rails we much override render_optional_error_file.

So, in app/controllers/application_controller.rb we must add the following code:

What this does is it recieves the error code and, rather than send out the static error pages to the client, it sends out the new rendered error pages located in the views.

The Views

According to the code above we will need to create a folder within views called errors. We will then create the following views:

• 404.html.erb
• 422.html.erb
• 500.html.erb
• unknown.html.erb

What you put in these views is entirely up to you.

Testing

In order to test this on your local machine you must insert the following code also into app/controllers/application_controller.rb:
Just remember to remove this last bit of code before pushing your application to your staging and/or production environments!

This is what I have come up with.

In your controller, you will create a multi-dimensional array of breadcrumbs in the following format:

[0]
    [title] Home
    [url] /
[1]
    [title] Blog
    [url] /blog/
[2]
    [title] Edit
    [url] NULL

You will then send this multi-dimensional array to the breadcrumb helper which will format the breadcrumbs and return the result. In this example, I utilize the power of Zend_View which allows me to set up a placeholder within the view or layout and through setting different parameters output the breadcrumbs in a neatly formatted unordered list.

Please note that for the sake of this post this is a very basic implementation of said helper class and therefore should be quite easy to extend. For anyone that would like more information please feel free to leave comments and questions and I’ll get back to you asap.

ALSO, sorry about the formatting. I’m working on it.

Your Helper File:

# ---- File: {library_root}/My/Helper/Breadcrumb.php ----
class My_Helper_Breadcrumb
{
  public static function process($crumbs = NULL)
  {
    if (is_array($crumbs))
    {
      $count = count($crumbs);

      for ($i = 0; $i < $count; $i++)
      {
        if ($i != ($count - 1))
          $output[] = ''. $crumbs[$i]['title'] .'';
        else
          $output[] = '' . $crumbs[$i]['title'] .'';
      }
    }
    else
    {
      $output = NULL;
    }

    return $output;
  }
}

Code within your controller:

# Initialize Bread Crumbs Array
$breadcrumbs = array(
    array('title' => 'Home', 'url' => '/'),
    array('title' => 'Blog', 'url' => '/blog/'));

# Add A Bread Crumb (or Two)
$breadcrumbs[] = array('title' => 'Edit', 'url' => '/blog/edit/');
$breadcrumbs[] = array('title' => $post_name, 'url' => NULL);

# Finalize Bread Crumbs
$this->view->placeholder('breadcrumbs')->exchangeArray( My_Helper_Breadcrumb::process($breadcrumbs) );

Code within your View or Layout

# Format & Display Bread Crumbs
$bc = $this->placeholder('breadcrumbs');
$bc->setPrefix("
\n
")
   ->setSeparator("
\n")
   ->setIndent(4)
   ->setPostfix("


\n");

echo $bc;

Mirroring the Data

We will use rsync for its ability to examine files and only transfer files that have been modified. The flags that are set tell rsync to:

Recurse into directories -r
Compress file data -z

rsync -rz user@remote_host /remote/path /local/path/of/copy

If you are simply trying to mirror your data to another server then that should do it for you. If you wish to take it one step further and retain multiple backups you should keep reading.

Data Retention

Since rsync only transfers files that have changed, what we will do is retain a copy of the server from the last rsync call so that we minimize both bandwidth and time. After every rsync call is complete we will archive and compress the current copy of the server.

cd /path/to/archives
tar -cf 'date +%F'.tar /local/path/of/copy
bzip2 'date +%F'.tar

That is all. It wasn’t that hard now was it?

Conclusion

After running these scripts, say, once a week, you will have a mirror of the server (dating back, in this case, at most a week) as well as as many prior backups your backup server can hold from previous weeks.

libraries/
    Zend/
        1.5.2/

site/
    www/ -> [/site_version/3.5]

site_version/
    2.0/
    3.0/
    3.5/
        application/
            cache/
            config/
            controllers/
            layouts/
            forms/
            views/
    library/
        My/
            Plugin/
        Zend/ -> [/libraries/Zend/1.5.2]
    public/
        css/
        js/
        media/

There are many situations where an application will call the database repeatedly with the same queries only to find that they return the exact same data sets time and time again. MySQL Query Caching caches the result set therefore removing the overhead of having to run through the database each time a specific query is called.

Initial Settings

Before you do anything, you will need to set the query cache type.

The settings are as follows:
0 – Do Not Cache
1 – Cache All
2 – Cache On Demand

Cache All
You may disable query caching for a specific query by setting SQL_NO_CACHE.

SELECT SQL_NO_CACHE * FROM tutorial;

Cache ON Demand
You may enable query caching for a specific query by setting SQL_CACHE.

SELECT SQL_CACHE * FROM tutorial;

Set Up

For this tutorial, I am simply going to utilize Cache All and to do this you must run the following query:

SET SESSION query_cache_type = 1;

This will instantaneously start the query cache and you should see the cache start to fill up.

SHOW STATUS LIKE '%Qcache%';

+-------------------------+----------+
| Variable_name           | Value    |
+-------------------------+----------+
| Qcache_free_blocks      | 11421    |
| Qcache_free_memory      | 82725432 |
| Qcache_hits             | 4467043  |
| Qcache_inserts          | 243158   |
| Qcache_lowmem_prunes    | 2066     |
| Qcache_not_cached       | 4183     |
| Qcache_queries_in_cache | 17831    |
| Qcache_total_blocks     | 47247    |
+-------------------------+----------+
8 rows in set (0.00 sec)

Query Cache Size
You may set your query cache size by using the following query:

SET GLOBAL query_cache_size = 52428800;

(The value is set in bytes. I have it set at 50Mb)

Read / Write Ratio
Make sure that you check up on your query cache because in some cases it might actually be detrimental to your site.

If your Qcache_inserts are close your Qcache_hits you might want to rethink using query caching as this means that you are nearing a 1:1 read/write ratio. Every time you write to the database, MySQL has to update the query cache and if those two numbers are close then Qcache might be doing the complete opposite of what it was designed to do.

Conclusion
With MySQL query caching enabled, you will generally see an increase in page loading times between five and fifteen percent. You will see more dramatic results on query-intensive pages.