From 737c7e859d2d7e2a14e58189f1a5bbd3bc5f3558 Mon Sep 17 00:00:00 2001 From: Boris Kolpackov Date: Tue, 25 Jan 2011 09:21:30 +0200 Subject: Manual proofreading fixes --- doc/manual.xhtml | 70 ++++++++++++++++++++++++++++---------------------------- 1 file changed, 35 insertions(+), 35 deletions(-) (limited to 'doc') diff --git a/doc/manual.xhtml b/doc/manual.xhtml index deb2bd8..5b5e3d6 100644 --- a/doc/manual.xhtml +++ b/doc/manual.xhtml @@ -1801,10 +1801,10 @@ class name

As we have seen in the previous chapter, some database operations create dynamically allocated instances of persistent classes and - return pointer to these instances. As we will see in later chapters, + return pointers to these instances. As we will see in later chapters, pointers are also used to establish relationships between objects (Chapter 6, Relationships) as well as to cache - persistent object in a session (Chapter 8, Session).

+ persistent objects in a session (Chapter 8, Session).

By default, all these mechanisms use raw pointers to return, pass, and cache objects. This is normally sufficient for applications @@ -2154,7 +2154,7 @@ update_age (database& db, person& p) pointers. If the identifier of the object being persisted is assigned by the database, these functions update the id member of the passed instance with the assigned value. All four functions return the object - id of the newly persistent object.

+ id of the newly persisted object.

If the database already contains an object of this type with this identifier, the persist() functions throw the @@ -2370,7 +2370,7 @@ transfer (database& db,

The first erase() function uses an object itself, in the form of an object reference, to delete its state from the - database. The next two functions accomplish the same but using + database. The next two functions accomplish the same result but using object pointers. Note that all three functions leave the passed object unchanged. It simply becomes transient. The last function uses the object id to identify the object to be deleted. If the @@ -2421,7 +2421,7 @@ t.commit ();

The first execute() function expects the SQL statement as a zero-terminated C-string. The last version expects the explicit statement length as the second argument and the statement itself - may contain '\0' characters, for example to represent + may contain '\0' characters, for example, to represent binary data, if the database system supports it. All three functions return the number of rows that were affected by the statement. For example:

@@ -2566,7 +2566,7 @@ namespace odb in Chapter 8, "Session".

The deadlock exception is thrown when a transaction - deadlock is detected by the database system. It can thrown by any + deadlock is detected by the database system. It can be thrown by any database function. See Section 3.4, "Transactions" for details.

@@ -3172,19 +3172,19 @@ private:

The complete version of the above code fragment and the other code - samples presented in this chapter can found in the container + samples presented in this chapter can be found in the container example in the odb-examples package.

A data member in a persistent class that is of a container type behaves like a value type. That is, when an object is made persistent, - the elements of the container are store in the database. Similarly, + the elements of the container are stored in the database. Similarly, when a persistent object is loaded from the database, the contents of the container are automatically loaded as well.

While an ordinary member is mapped to one or more columns in the object's table, a member of a container type is mapped to a separate table. The exact schema of such a table depends on the kind of - a container. ODB defines the following container kinds: ordered, + container. ODB defines the following container kinds: ordered, set, multiset, map, and multimap. The container kinds and the contents of the tables to which they are mapped are discussed in detail in the following sections.

@@ -3244,8 +3244,8 @@ private: persistent class instance of which the container is a member. The second column contains the element index within a container. And the last column contains the element value. If the object - id or element value are composite, then instead of a single - column they can occupy multiple columns.

+ id or element value are composite, then, instead of a single + column, they can occupy multiple columns.

Consider the following persistent object as an example:

@@ -3333,8 +3333,8 @@ private: two columns. The first column contains the object id of a persistent class instance of which the container is a member. And the second column contains the element value. If the object - id or element value are composite, then instead of a single - column they can occupy multiple columns.

+ id or element value are composite, then, instead of a single + column, they can occupy multiple columns.

Consider the following persistent object as an example:

@@ -3451,7 +3451,7 @@ private:

To achieve this you will need to implement the container_traits class template specialization for - your container. First determine the container kind (ordered, set, + your container. First, determine the container kind (ordered, set, multiset, map, or multimap) for your container type. Then use a specialization for one of the standard C++ containers found in the common ODB runtime library (libodb) as a base @@ -3474,9 +3474,9 @@ private:

Now, whenever we compile a header file that uses the hashtable - container, we can pass the following option to make sure it - is recognized by the ODB compiler as a container and the traits - file is included in the generated code:

+ container, we can specify the following command line option to + make sure it is recognized by the ODB compiler as a container + and the traits file is included in the generated code:

 --options-file hashtable.options
@@ -4460,9 +4460,9 @@ t.commit ();

Now, whenever we compile a header file that uses smart_ptr, - we can pass the following option to make sure it is recognized by the - ODB compiler as a smart pointer and the traits file is included in the - generated code:

+ we can specify the following command line option to make sure it is + recognized by the ODB compiler as a smart pointer and the traits file + is included in the generated code:

 --options-file smart-ptr.options
@@ -4484,7 +4484,7 @@ t.commit ();
 
   
7 Composite Value Types

 
-  
Composite value type is a class or struct
+  
A composite value type is a class or struct
      type that is mapped to more than one database column. To declare
      a composite value type we use the db value pragma,
      for example:

@@ -4501,7 +4501,7 @@ class basic_name

The complete version of the above code fragment and the other code - samples presented in this chapter can found in the composite + samples presented in this chapter can be found in the composite example in the odb-examples package.

A composite value type does not have to define a default constructor, @@ -4807,7 +4807,7 @@ CREATE TABLE `person_nickname` (

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

@@ -4903,11 +4903,11 @@ namespace odb

The session constructor creates a new session and sets it as a - current session for this thread. If we try to create a session - while there is already a current session in effect, this constructor - throws the odb::already_in_session exception. The - destructor clears the current session for this thread if this - session is the current one.

+ current session for this thread. If we try to create another + session while there is already a current session in effect, + the constructor throws the odb::already_in_session + exception. The destructor clears the current session for this + thread if this session is the current one.

The static current() accessor returns the currently active session for this thread. If there is no active session, this function @@ -5334,9 +5334,9 @@ class person specifiers with the same names (Section 9.3, "Data Member Pragmas"). The behavior of such specifiers for members is similar to that for value types. The only difference - is the scope. A particular value type specifier applies to all + is the scope. A particular value type specifier applies to all the members of this value type that don't have a pre-member version - of the specifier. While the member specifier always applies only + of the specifier, while the member specifier always applies only to a single member. In other words, member specifiers take precedence over parameters specified with value specifiers.

@@ -5380,7 +5380,7 @@ private:

The possible database values for the C++ true value could be "true", or "TRUE", or "True". - Or, maybe, all of the above are valid. The ODB compiler has no way + Or, maybe, all of the above could be valid. The ODB compiler has no way of knowing how your application wants to convert bool to a string and back. To support such custom value type mappings, ODB allows you to provide your own database conversion functions @@ -5422,7 +5422,7 @@ typedef std::vector<shared_ptr<account> > accounts;

9.2.3 unordered

The unordered specifier specifies that the ordered - container should be stored in the database unordered. The database + container should be stored unordered in the database. The database table for such a container will not contain the index column and the order in which elements are retrieved from the database may not be the same as the order in which they were stored. For example:

@@ -5655,9 +5655,9 @@ typedef std::map<unsigned short, float> age_weight_map; specifiers with the same names (Section 9.2, "Value Type Pragmas"). The behavior of such specifiers for members is similar to that for value types. The only difference - is the scope. A particular value type specifier applies to all + is the scope. A particular value type specifier applies to all the members of this value type that don't have a pre-member version - of the specifier. While the member specifier always applies only + of the specifier, while the member specifier always applies only to a single member. In other words, member specifiers take precedence over parameters specified with value specifiers.

@@ -5856,7 +5856,7 @@ private:

9.3.8 unordered

The unordered specifier specifies that a member of - an ordered container type should be stored in the database unordered. + an ordered container type should be stored unordered in the database. The database table for such a member will not contain the index column and the order in which elements are retrieved from the database may not be the same as the order in which they were stored. For example:

-- cgit v1.1