[Zodb-checkins] CVS: ZODB3/Doc/guide - prog-zodb.tex:1.3.10.3

[Tim Peters]

Update of /cvs-repository/ZODB3/Doc/guide
In directory cvs.zope.org:/tmp/cvs-serv32556/Doc/guide

Modified Files:
      Tag: Zope-2_7-branch
	prog-zodb.tex 
Log Message:
Trimmed trailing whitespace.


=== ZODB3/Doc/guide/prog-zodb.tex 1.3.10.2 => 1.3.10.3 ===
--- ZODB3/Doc/guide/prog-zodb.tex:1.3.10.2	Mon Mar  7 13:51:38 2005
+++ ZODB3/Doc/guide/prog-zodb.tex	Mon Mar  7 14:57:06 2005
@@ -3,7 +3,7 @@
 %   How ZODB works (ExtensionClass, dirty bits)
 %   Installing ZODB
 %   Rules for Writing Persistent Classes
-   
+
 
 \section{ZODB Programming}
 
@@ -33,8 +33,8 @@
 
 \subsection{How ZODB Works}
 
-The ZODB is conceptually simple.  Python classes subclass a 
-\class{Persistent} class to become ZODB-aware. 
+The ZODB is conceptually simple.  Python classes subclass a
+\class{Persistent} class to become ZODB-aware.
 Instances of persistent objects are brought in from a permanent
 storage medium, such as a disk file, when the program needs them, and
 remain cached in RAM.  The ZODB traps modifications to objects, so
@@ -51,14 +51,14 @@
 software offers protection against such corruption by supporting four
 useful properties, Atomicity, Consistency, Isolation, and Durability.
 In computer science jargon these four terms are collectively dubbed
-the ACID properties, forming an acronym from their names.  
+the ACID properties, forming an acronym from their names.
 
 The ZODB provides all of the ACID properties.  Definitions of the
 ACID properties are:
 
 \begin{itemize}
 
-\item[Atomicity] means that any changes to data made during a transaction 
+\item[Atomicity] means that any changes to data made during a transaction
 are all-or-nothing.  Either all the changes are applied, or none of
 them are.  If a program makes a bunch of modifications and then
 crashes, the database won't be partially modified, potentially leaving
@@ -181,7 +181,7 @@
 \begin{verbatim}
 dbroot = conn.root()
 
-# Ensure that a 'userdb' key is present 
+# Ensure that a 'userdb' key is present
 # in the root
 if not dbroot.has_key('userdb'):
     from BTrees.OOBTree import OOBTree
@@ -195,10 +195,10 @@
 this transaction.
 
 \begin{verbatim}# Create new User instance
-newuser = User() 
+newuser = User()
 
 # Add whatever attributes you want to track
-newuser.id = 'amk' 
+newuser.id = 'amk'
 newuser.first_name = 'Andrew' ; newuser.last_name = 'Kuchling'
 ...
 
@@ -226,7 +226,7 @@
 \begin{verbatim}>>> newuser
 <User instance at 81b1f40>
 >>> newuser.first_name           # Print initial value
-'Andrew'         
+'Andrew'
 >>> newuser.first_name = 'Bob'   # Change first name
 >>> newuser.first_name           # Verify the change
 'Bob'
@@ -249,10 +249,10 @@
 
 \item If you modify a mutable object that's the value of an object's
 attribute, the ZODB can't catch that, and won't mark the object as
-dirty.  
+dirty.
 The solution is to either set the dirty bit yourself when you modify
 mutable objects, or use a wrapper for Python's lists and dictionaries
-(\class{PersistentList}, 
+(\class{PersistentList},
 \class{PersistentMapping})
 that will set the dirty bit properly.
 
@@ -262,10 +262,10 @@
 arithmetic operations: \method{__radd__}, \method{__rsub__}, and so
 forth.
 
-\item Recent versions of the ZODB allow writing a class with 
+\item Recent versions of the ZODB allow writing a class with
 \method{__setattr__} , \method{__getattr__}, or \method{__delattr__} methods.
 (Older versions didn't support this at all.)
-If you write such a \method{__setattr__} or \method{__delattr__} method, 
+If you write such a \method{__setattr__} or \method{__delattr__} method,
 its code has to set the dirty bit manually.
 
 \item A persistent class should not have a \method{__del__} method.
@@ -309,7 +309,7 @@
 \end{verbatim}
 
 An obsolete way of doing this that's still supported is calling the
-\method{__changed__()} method instead, but setting \member{_p_changed} 
+\method{__changed__()} method instead, but setting \member{_p_changed}
 is the preferred way.
 
 You can hide the implementation detail of having to mark objects as
@@ -330,12 +330,12 @@
 Alternatively, you could use a ZODB-aware list or mapping type that
 handles the dirty bit for you.  The ZODB comes with a
 \class{PersistentMapping} class, and I've contributed a
-\class{PersistentList} class that's included in my ZODB distribution, 
+\class{PersistentList} class that's included in my ZODB distribution,
 and may make it into a future upstream release of Zope.
 
 % XXX It'd be nice to discuss what happens when an object is ``ghosted'' (e.g.
 % you set an object's _p_changed = None).  The __p_deactivate__ method should
-% not be used (it's also obsolete). 
+% not be used (it's also obsolete).
 
 \subsubsection{Some Special Methods Don't Work}
 
@@ -347,7 +347,7 @@
 
 This is a moderately annoying limitation.  It means that the
 \class{PersistentList} class can't implement comparisons with regular
-sequence objects, and therefore statements such as 
+sequence objects, and therefore statements such as
 \verb|if perslist==[]| don't do what you expect; instead of performing the correct
 comparison, they return some arbitrary fixed result, so the \code{if}
 statement will always be true or always be false.  There is no good
@@ -371,7 +371,7 @@
 
 While ExtensionClasses try to behave as much like regular Python
 instances as possible, they are still not instances, and
-\function{type()} doesn't return the \code{InstanceType} object, so 
+\function{type()} doesn't return the \code{InstanceType} object, so
 no attempt is ever made to call \method{__cmp__}.  Perhaps Python 2.2
 will repair this.
 
@@ -452,7 +452,7 @@
 different class instances, then there's no longer any easy way to find
 them all, short of writing a generalized object traversal function
 that would walk over every single object in a ZODB, checking each one
-to see if it's an instance of \class{User}.  
+to see if it's an instance of \class{User}.
 
 Some OODBs support a feature called extents, which allow quickly
 finding all the instances of a given class, no matter where they are