summaryrefslogtreecommitdiffstats
path: root/user_guide/database/caching.html
diff options
context:
space:
mode:
authoradmin <devnull@localhost>2006-10-06 08:05:02 +0200
committeradmin <devnull@localhost>2006-10-06 08:05:02 +0200
commit0a35e3d53fcfd27427bcc0a5602eaa3e289888a1 (patch)
tree8f98b907c81eb411f90d88dd4e7dd3a78a3aba40 /user_guide/database/caching.html
parentc5f7fa3f8fea283b51ee6cd80b36b2112b2e81db (diff)
Diffstat (limited to 'user_guide/database/caching.html')
-rw-r--r--user_guide/database/caching.html46
1 files changed, 35 insertions, 11 deletions
diff --git a/user_guide/database/caching.html b/user_guide/database/caching.html
index 8bf534352..f78dc2f33 100644
--- a/user_guide/database/caching.html
+++ b/user_guide/database/caching.html
@@ -81,43 +81,47 @@ when caching is enabled. Do NOT load this class manually.<br /><br />
<li>Enable the caching feature, either globally by setting the preference in your <dfn>application/config/database.php</dfn> file, or manually as described below.</li>
</ul>
+<p>Once enabled, caching will happen automatically whenever a web pages that contains database queries is loaded.</p>
+
<h2>How Does Caching Work?</h2>
<p>Code Igniter's query caching system happens dynamically when your pages are viewed.
-When caching is enabled, the first time a webpage is loaded, the query result object will
+When caching is enabled, the first time a web page is loaded, the query result object will
be serialized and stored in a text file on your server. The next time the page is loaded the cache file will be used instead of
accessing your database. Your database usage can effectively be reduced to zero for any pages that have been cached.</p>
<p>Only <dfn>read-type</dfn> (SELECT) queries can be cached, since these are the only type of queries that produce a result.
<dfn>Write-type</dfn> (INSERT, UPDATE, etc.) queries, since they don't generate a result, will not be cached by the system.</p>
-<p>Cache files do NOT expire. Any queries that have been cached will remain cached until you delete them. The caching system does
-have an "auto-delete"feature, as described below. It also lets you manually clear caches associated with individulal pages, or
-you can delete the entire collection of cache files.</p>
+<p>Cache files DO NOT expire. Any queries that have been cached will remain cached until you delete them. The caching system
+permits you clear caches associated with individual pages, or you can delete the entire collection of cache files.
+Typically you'll to use the housekeeping functions described below to delete cache files after certain
+events take place, like when you've added new information to your database.</p>
<h2>Will Caching Improve Your Site's Performance?</h2>
-<p>Maybe. Whether you see a performance gain as a result of caching depends on many factors.
-For example, if you have a highly optimized database under very little load, you probably won't see a performance boost.
+<p>Getting a performance gain as a result of caching depends on many factors.
+If you have a highly optimized database under very little load, you probably won't see a performance boost.
If your database is under heavy use you probably will see an improved response, assuming your filesystem is not
-overly taxed. Remember that caching simply changes how your information is retrieved, shifting it from being a database
+overly taxed. Remember that caching simply changes how your information is retrieved, shifting it from being a database
operation to a filesystem one.</p>
-<p>In some clustered server environments caching may be detrimental since filesystem operations are so intense.
-On single servers (particularly in shared enironments) caching will probably be beneficial. Unfortunately there is no
+<p>In some clustered server environments, for example, caching may be detrimental since filesystem operations are so intense.
+On single servers in shared environments, caching will probably be beneficial. Unfortunately there is no
single answer to the question of whether you should cache your database. It really depends on your situation.</p>
<h2>How are Cache Files Stored?</h2>
<p>Code Igniter places the result of EACH query into its own cache file. Sets of cache files are further organized into
-sub-folders corrsponding to your controller functions.</p>
+sub-folders corresponding to your controller functions. To be precise, the sub-folders are named identically to the
+first two segments of your URI (the controller class name and function name).</p>
<p>For example, let's say you have a controller called <dfn>blog</dfn> with a function called <dfn>comments</dfn> that
contains three queries. The caching system will create a cache folder
called <kbd>blog_comments</kbd>, into which it will write three cache files.</p>
-<p>If your have dynamic queries that change based on inormation in your URI (when using pagination, for example), each instance of
+<p>If you use dynamic queries that change based on information in your URI (when using pagination, for example), each instance of
the query will produce its own cache file. It's possible, therefore, to end up with many times more cache files than you have
queries.</p>
@@ -130,6 +134,26 @@ controller function that serves up your comments. You'll find two delete functi
clear data.</p>
+<h2>Not All Database Functions Work with Caching</h2>
+
+<p>Lastly, we need to point out that the result object that is cached is a simplified version of the full result object. For that reason,
+some of the query result functions are not available for use.</p>
+
+<p>The following functions <kbd>ARE NOT</kbd> available when using a cached result object:</p>
+
+<ul>
+<li>num_fields()</li>
+<li>field_names()</li>
+<li>field_data()</li>
+<li>free_result()</li>
+</ul>
+
+<p>Also, the two database resources (result_id and conn_id) are not available when caching, since result resources only
+pertain to run-time operations.</p>
+
+
+<br />
+
<h1>Function Reference</h1>