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

[Jeremy Hylton]

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

Modified Files:
      Tag: ZODB3-3_1-branch
	prog-zodb.tex 
Log Message:
Flesh out what consistency means.
Replace BerkeleyStorage reference with bsddb3Storage.
Change B-tree to BTree.


=== ZODB3/Doc/guide/prog-zodb.tex 1.2.4.1 => 1.2.4.2 ===
--- ZODB3/Doc/guide/prog-zodb.tex:1.2.4.1	Fri Oct  4 13:35:52 2002
+++ ZODB3/Doc/guide/prog-zodb.tex	Fri Oct  4 14:19:03 2002
@@ -113,10 +113,16 @@
 
 \item[Consistency] means that the data cannot be placed into a
 logically invalid state; sanity checks can be written and enforced.
-Usually this is done by defining a database schema, and requiring the
-data always matches the schema.  For example, this might enforce that
-the \code{order_number} attribute is always an integer, and not a
-string, tuple, or other object.
+Usually this is done by defining a database schema, and requiring
+the data always matches the schema.  There are two typical
+approaches to consistency.  One is to enforce rules about the types
+of objects and attribute; for example, enforce that the
+\code{order_number} attribute is always an integer, and not a
+string, tuple, or other object.  Another is to guarantee consistency
+across data structures; for example, that any object with an
+\code{order_number} attribute must also appear in the
+\code{orders_table} object.  In general, atomicity and isolation make
+it possible for applications to provide consistency.
 
 \item[Isolation] means that two programs or threads running in two
  different transactions cannot see each other's changes until they
@@ -144,7 +150,7 @@
  storing and retrieving objects from some form of long-term storage.
  A few different types of Storage have been written, such as
  \class{FileStorage}, which uses regular disk files, and
- \class{BerkeleyStorage}, which uses Sleepycat Software's BerkeleyDB
+ \class{bsddb3Storage}, which uses Sleepycat Software's BerkeleyDB
  database.  You could write a new Storage that stored objects in a
  relational database or Metakit file, for example, if that would
  better suit your application.  Two example storages,
@@ -156,7 +162,7 @@
  created per process.
 
  \item Finally, the \class{Connection} class caches objects, and moves
- them into and out of object storage.  A multi-threaded program can
+ them into and out of object storage.  A multi-threaded program should
  open a separate \class{Connection} instance for each thread.
  Different threads can then modify objects and commit their
  modifications independently.
@@ -545,7 +551,7 @@
 of object references is quite structured, making it easy to find all
 the instances of the class being modified.  For example, if all
 \class{User} objects can be found inside a single dictionary or
-B-tree, then it would be a simple matter to loop over every
+BTree, then it would be a simple matter to loop over every
 \class{User} instance with a \keyword{for} statement.
 This is more difficult if your object graph is less structured; if
 \class{User} objects can be found as attributes of any number of