Proofreading changes

1 files changed, 35 insertions, 24 deletions

diff --git a/view/employee.hxx b/view/employee.hxx
index 4ff4f1b..110cb9e 100644
--- a/view/employee.hxx
+++ b/view/employee.hxx
@@ -143,8 +143,8 @@ private:
   shared_ptr<employer> employed_by_;
 };
 
-// We also have a "legacy" employee_extra table that is not mapped to any
-// object. It has the following columns:
+// We also have the "legacy" employee_extra table that is not mapped to any
+// persistent class. It has the following columns:
 //
 // CREATE TABLE employee_extra(
 //   employee_id INTEGER NOT NULL,
@@ -153,10 +153,10 @@ private:
 //
 
 // A simple view with a single associated object. It allows us to get
-// the name of an employee without loading any of the other data, such
-// as the country and employer objects. The first and last data members
-// in the view are automatically assumed to correspond to the first_ and
-// last_ members in the employee object.
+// the name of an employee without loading any of the other parts, such
+// as the referenced country and employer objects. The first and last
+// data members in the view are automatically associated to the first_
+// and last_ members in the employee object.
 //
 #pragma db view object(employee)
 struct employee_name
@@ -177,14 +177,13 @@ struct employee_count
 };
 
 // A simple view with two associated object. It allows us to get the
-// name of an employee and its employer without loading any other data.
-// Because there is a relationship between the employee and employer
-// objects (employee::employed_by_), the ODB compiler automatically
-// used this relationship as a join condition. Also, similar to the
-// employee_name view, the first and last data members are automatically
-// assumed to correspond to the first_ and last_ members in the employee
-// object. For the employer_name member we provide an explicit member
-// reference.
+// name of an employee and its employer without loading any other parts.
+// Because there is an unambiguous relationship between the employee and
+// employer objects (employee::employed_by_), the ODB compiler is able to
+// automatically use this relationship as a join condition. Also, similar
+// to the employee_name view, the first and last data members are auto-
+// associated to the first_ and last_ members in the employee object.
+// For the employer_name member we provide an explicit member reference.
 //
 #pragma db view object(employee) object(employer)
 struct employee_employer
@@ -196,10 +195,9 @@ struct employee_employer
   std::string employer_name;
 };
 
-// A more interesting aggregate view using GROUP BY. It allows us to
-// calculate the min/max age of employees for each employer. Here we
-// use the C++-integrated syntax for the query condition template with
-// a placeholder (?).
+// A more interesting aggregate view that uses the GROUP BY clause. It
+// allows us to calculate the min/max ages of employees for each employer.
+// Here we use the query condition with a placeholder (?).
 //
 #pragma db view object(employee) object(employer) \
   query ((?) + "GROUP BY" + employer::name_)
@@ -216,8 +214,8 @@ struct employer_age
 };
 
 // A more complex view with three associated objects, two of which are
-// of the same type, which requires us to use aliases and disambiguate
-// the relationships used to join each object.
+// of the same type. This requires us to use aliases and disambiguate
+// the relationships used to associate each object.
 //
 #pragma db view object(employee) \
   object(country = res_country: employee::residence_) \
@@ -234,9 +232,9 @@ struct employee_country
   std::string nat_country_name;
 };
 
-// A native view. A native view provides a complete query and is normally
-// based on an ad-hoc table. This view allows us to load the employee
-// vacation information from the legacy employee_extra table.
+// An example of a native view that provides a complete query and is based
+// on an ad-hoc table. This view allows us to load the employee vacation
+// information from the legacy employee_extra table.
 //
 #pragma db view query("SELECT employee_id, vacation_days " \
                       "FROM view_employee_extra")
@@ -249,6 +247,19 @@ struct employee_vacation
   unsigned short days;
 };
 
+// A more robust implementation of the above view as a table view instead
+// of a native view.
+//
+#pragma db view table("view_employee_extra")
+struct employee_vacation1
+{
+  #pragma db column("employee_id") type("INTEGER")
+  unsigned long id;
+
+  #pragma db column("vacation_days") type("INTEGER")
+  unsigned short days;
+};
+
 // An improved version of the previous view that extracts the employee
 // first and last names instead of the id. To get the names we need to
 // add the employee object to this view and use a custom join condition
@@ -265,7 +276,7 @@ struct employee_vacation2
   unsigned short days;
 };
 
-// An advanced view that joins two objects via a legacy table. It returns
+// A mixed view that associates two objects and a legacy table. It returns
 // the previous employer information for each employee.
 //
 #pragma db view object(employee) \