From edb01383731c2306aa5441a076a5ad49bb6b22df Mon Sep 17 00:00:00 2001 From: Boris Kolpackov Date: Wed, 19 Jan 2011 19:05:36 +0200 Subject: Fix references in manual --- doc/manual.xhtml | 66 +++++++++++++++++++++++++++++++++++--------------------- 1 file changed, 41 insertions(+), 25 deletions(-) (limited to 'doc') diff --git a/doc/manual.xhtml b/doc/manual.xhtml index 17e9f42..3a91c4d 100644 --- a/doc/manual.xhtml +++ b/doc/manual.xhtml @@ -3186,7 +3186,8 @@ private: in detail in the following sections.

Containers in ODB can contain simple value types, composite value - types (see @@), and pointers to objects (see @@). Containers of + types (Chapter 5, "Containers"), and pointers to + objects (Chapter 6, "Relationships"). Containers of containers, either directly or indirectly via a composite value type, are not allowed. A key in map and multimap containers can be a simple or composite value type but not a pointer to an object. @@ -3506,7 +3507,8 @@ private: for a custom smart pointer as discussed later in Section 6.4, "Using Custom Smart Pointers". Any supported smart pointer can be used in a data member as long as it can be - explicitly constructed from the canonical object pointer (@@ ref). + explicitly constructed from the canonical object pointer + (Section 3.2, "Object Pointers"). For example, we can use weak_ptr if the object pointer is shared_ptr.

@@ -3616,7 +3618,8 @@ unsigned long john_id, jane_id;

The only notable line in the above code is the creation of a session before the second transaction starts. As discussed in - Chapter @@ ref, a session acts as a cache of persistent objects. + Chapter 8, "Session", a session acts as a cache + of persistent objects. By creating a session before loading the employee objects we make sure that their employer_ pointers point to the same employer object. Without a @@ -4538,15 +4541,19 @@ private: example in the odb-examples package.

The members of a composite value can be other value types (either - simple or composite), containers (@@ ref), and object pointers (@@ ref). + simple or composite), containers (Chapter 5, + "Containers"), and pointers to objects (Chapter 6, + "Relationships"). Similarly, a composite value type can be used in object members, as an element in a container, and as a base for another composite value type. In particular, composite value types can be used as - element types in set containers (@@ ref) and as key types in map - containers (@@ ref). A composite value type that is used as an - element of a container cannot contain other containers since - containers of containers are not allowed. The following example - illustrates some of the possible use cases:

+ element types in set containers (Section 5.2, "Set + and Multiset Containers") and as key types in map containers + (Section 5.3, "Map and Multimap Containers"). + A composite value type that is used as an element of a container + cannot contain other containers since containers of containers + are not allowed. The following example illustrates some of the + possible use cases:

 #pragma db value
@@ -4622,7 +4629,8 @@ t.commit ();
 
   
Customizing a column name for a data member of a simple value
      type is straightforward: we simply specify the desired name with
-     the db column pragma (@@ ref). For composite value
+     the db column pragma (Section
+     9.3.4, "column"). For composite value
      types things are slightly more complicated since it is mapped to
      multiple columns. Consider the following example:

 
@@ -4723,11 +4731,13 @@ CREATE TABLE person (
   
The same principal applies when a composite value type is used
      as an element of a container, except that instead of
      db column either the db value_column
-     (@@ ref) or db key_column (@@ ref) pragmas are used to
-     specify the column prefix.

+     (Section 9.3.16, "value_column") or
+     db key_column
+     (Section 9.3.15, "key_column")
+     pragmas are used to specify the column prefix.

 
   
When a composite value type contains a container, an extra table
-     is used to store the elements (@@ ref Chapter X, "Containers").
+     is used to store the elements (Chapter 5, "Containers").
      The names of such tables are constructed in a way similar to the
      column names, except that by default both the object name and the
      member name are used as a prefix. For example:

@@ -4767,7 +4777,8 @@ CREATE TABLE person (

To customize the container table name we can use the - db table (@@ ref) pragma, for example:

+ db table pragma (Section + 9.3.9, "table"), for example:

 #pragma db value
@@ -4807,9 +4818,9 @@ CREATE TABLE `person_nickname` (
   
8 Session

 
   
A session is an application's unit of work that may encompass several
-     database transactions (@@ ref Transaction). In this version of ODB a
-     session is just an object cache. In the future versions it will provide
-     additional functionality, such as automatic object state change flushing
+     database transactions. In this version of ODB a session is just an
+     object cache. In the future versions it will provide additional
+     functionality, such as automatic object state change flushing
      and optimistic concurrency.

 
   
Each thread of execution in an application can have only one active
@@ -4929,14 +4940,18 @@ namespace odb
   
8.1 Object Cache

 
   
A session is an object cache. Every time an object is made persistent
-     by calling the database::persist() function (@@ ref), loaded
+     by calling the database::persist() function
+     (Section 3.5, "Making Objects Persistent"), loaded
      by calling the database::load() or database::find()
-     function (@@ ref), or loaded by iterating over a query result (@@ ref),
-     the pointer to the persistent object, in the form of the canonical object
-     pouinter (@@ ref), is stored in the session. For as long as the
+     function (Section 3.6, "Loading Persistent Objects"),
+     or loaded by iterating over a query result (Section 4.4,
+     "Query Result"), the pointer to the persistent object, in the form
+     of the canonical object pointer (Section 3.2, "Object
+     Pointers"), is stored in the session. For as long as the
      session is in effect, any subsequent calls to load the same object will
      return the cached instance. When an object's state is deleted from the
-     database with the database::erase() function (@@ ref), the
+     database with the database::erase() function
+     (Section 3.8, "Deleting Persistent Objects"), the
      cached object pointer is removed from the session. For example:

 
   
@@ -4953,7 +4968,8 @@ t.commit ();
 
 
   
The per-object caching policies depend on the object pointer kind
-     (@@ ref). Objects with a unique pointer, such as std::auto_ptr,
+     (Section 6.4, "Using Custom Smart Pointers").
+     Objects with a unique pointer, such as std::auto_ptr,
      as an object pointer are never cached since it is not possible to have
      two such pointers pointing to the same object. When an object is
      persisted via a pointer or loaded as a dynamically allocated instance,
@@ -5220,8 +5236,8 @@ class person
      ODB compiler option, is used. If this option is not specified
      either, then the raw pointer is used by default.

 
-  
For additional information on object pointers, refer to
-     Section @@, "".

+  
For additional information on object pointers refer to
+     Section 3.2, "Object Pointers".

 
   
9.2 Value Type Pragmas

 
-- 
cgit v1.1