aboutsummaryrefslogtreecommitdiff
path: root/view/employee.hxx
diff options
context:
space:
mode:
Diffstat (limited to 'view/employee.hxx')
-rw-r--r--view/employee.hxx59
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) \