Author: wyoung
Date: Mon Apr 13 21:02:12 2009
New Revision: 2499
URL: http://svn.gna.org/viewcvs/mysqlpp?rev=2499&view=rev
Log:
Tweaks
Modified:
trunk/doc/userman/tutorial.dbx
Modified: trunk/doc/userman/tutorial.dbx
URL:
http://svn.gna.org/viewcvs/mysqlpp/trunk/doc/userman/tutorial.dbx?rev=2499&r1=2498&r2=2499&view=diff
==============================================================================
--- trunk/doc/userman/tutorial.dbx (original)
+++ trunk/doc/userman/tutorial.dbx Mon Apr 13 21:02:12 2009
@@ -784,19 +784,19 @@
<title>Reference Counting</title>
<para>To avoid unnecessary buffer copies, both
- <classname>STA</classname> and <classname>String</classname> are
- implemented in terms of a reference-counted copy-on-write buffer
- scheme. Both classes share the same underlying mechanism, and so
- are interoperable. This means that if you construct one of these
- objects from another, it doesn’t actually copy the string
- data, it only copies a pointer to the data buffer, and increments
- its reference count. If the object has new data assigned to it or
- it’s otherwise modified, it decrements its reference count
- and creates its own copy of the buffer. This has a lot of
- practical import, such as the fact that
- <methodname>Row::operator[]</methodname> can return
- <classname>String</classname> by value, and it’s still
- efficient.</para>
+ <classname>STA</classname> and <classname>String</classname>
+ are implemented in terms of a reference-counted copy-on-write
+ buffer scheme. Both classes share the same underlying mechanism,
+ and so are interoperable. This means that if you construct
+ one of these objects from another, it doesn’t actually
+ copy the string data, it only copies a pointer to the data
+ buffer, and increments its reference count. If the object
+ has new data assigned to it or it’s otherwise modified,
+ it decrements its reference count and creates its own copy of
+ the buffer. This has a lot of practical import, such as the
+ fact that even though <methodname>Row::operator[]</methodname>
+ returns <classname>String</classname>s by value, it’s
+ still efficient.</para>
</sect3>
</sect2>
@@ -819,25 +819,25 @@
file system, you should use it for big, nondecomposable blocks
of binary data in most cases.</para>
- <para>A common example people use when discussing this is
- images in database-backed web applications. If you store the
- image in the database, you have to write code to retrieve the
- image from the database and send it to the client; there’s
- more overhead, and less efficient use of the system’s I/O
- caching system. If you store the image in the filesystem, all
- you have to do is point the web server to the directory where
- the images live, and put a URL for that image in your generated
- HTML. Because you’re giving the web server a direct path
- to a file on disk, operation is far more efficient. Web servers
- are very good at slurping whole files off of disk and sending
- them out to the network, and operating systems are very good at
- caching file accesses. Plus, you avoid the overhead of pushing the
- data through the high-level language your web app is written in,
- which is typically an interpreted language, not C++. Some people
- still hold out on this, claiming superior security and other
- features of a database engine, but I call bunk on that, too.
- Modern web servers and file systems are capable of very granular
- access control.</para>
+ <para>A common example people use when discussing this is images
+ in database-backed web applications. If you store the image in the
+ database, you have to write code to retrieve the image from the
+ database and send it to the client; there’s more overhead,
+ and less efficient use of the system’s I/O caching system. If
+ you store the image in the filesystem, all you have to do is
+ point the web server to the directory where the images live,
+ and put a URL for that image in your generated HTML. Because
+ you’re giving the web server a direct path to a file on
+ disk, operation is far more efficient. Web servers are very
+ good at slurping whole files off of disk and sending them out
+ to the network, and operating systems are very good at caching
+ file accesses. Plus, you avoid the overhead of pushing the data
+ through the high-level language your web app is written in, which
+ is typically an interpreted language, not C++. Some people still
+ hold out on this, claiming that database engines have superior
+ security features, but I call bunk on that, too. Operating systems
+ and web servers are capable of building access control systems
+ every bit as granular and secure as a database system.</para>
<para>Occasionally you really do need to store a nondecomposable
block of binary data in the database. For such cases, modern
_______________________________________________
Mysqlpp-commits mailing list
[email protected]
https://mail.gna.org/listinfo/mysqlpp-commits
