From 3d643f17ae30d1a3c49f9bf3968f706898bea842 Mon Sep 17 00:00:00 2001 From: Boris Kolpackov Date: Fri, 17 Aug 2012 10:08:14 +0200 Subject: Minor documentation changes --- doc/manual.xhtml | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) (limited to 'doc/manual.xhtml') diff --git a/doc/manual.xhtml b/doc/manual.xhtml index 395c90e..ffc485c 100644 --- a/doc/manual.xhtml +++ b/doc/manual.xhtml @@ -1207,16 +1207,17 @@ private: unnecessary.

The final change adds a data member called id_ which - is preceded by another pragma. In ODB every persistent object must - have a unique, within its class, identifier. Or, in other words, - no two persistent instances of the same type have equal - identifiers. For our class we use an integer id. The - db id auto pragma that precedes the id_ - member tells the ODB compiler that the following member is the - object's identifier. The auto specifier indicates that it - is a database-assigned id. A unique id will be automatically generated - by the database and assigned to the object when it is made - persistent.

+ is preceded by another pragma. In ODB every persistent object normally + has a unique, within its class, identifier. Or, in other words, no two + persistent instances of the same type have equal identifiers. While it + is possible to define a persistent class without an object id, the number + of database operations that can be performed on such a class is limited. + For our class we use an integer id. The db id auto + pragma that precedes the id_ member tells the ODB compiler + that the following member is the object's identifier. The + auto specifier indicates that it is a database-assigned + id. A unique id will be automatically generated by the database and + assigned to the object when it is made persistent.

In this example we chose to add an identifier because none of the existing members could serve the same purpose. However, if @@ -1226,7 +1227,7 @@ private: identification (SSN in the United States or ID/passport number in other countries), then we could use that as an id. Or, if we stored an email associated with each person, then we could - have used that since each person is presumed to have a unique + have used that if each person is presumed to have a unique email address, for example:

@@ -2203,7 +2204,7 @@ class person
      Section 4.4, "Query Result").

The object id can be of a simple or composite (Section - 7.2.1, "Composite Object Ids") value type which should be + 7.2.1, "Composite Object Ids") value type and should be default-constructible.

If an object class has private or protected non-transient data -- cgit v1.1