diff options
Diffstat (limited to 'inheritance/polymorphism/README')
-rw-r--r-- | inheritance/polymorphism/README | 69 |
1 files changed, 69 insertions, 0 deletions
diff --git a/inheritance/polymorphism/README b/inheritance/polymorphism/README new file mode 100644 index 0000000..4fb3e15 --- /dev/null +++ b/inheritance/polymorphism/README @@ -0,0 +1,69 @@ +This example shows how to use polymorphism inheritance with ODB. This +inheritance style is normally used to provide polymorphic behavior through +a common interface. The base class defines a number of virtual functions and, +normally, a virtual destructor while the derived classes provide specific +implementations of these virtual functions. + +The other commonly used inheritance style is reuse inheritance. Refer to the +inheritance/reuse example for more information on this style. + +The example consists of the following files: + +employee.hxx +employee.cxx + Header and source files defining the 'person' abstract polymorphic + persistent class as well as the 'employee' and 'contractor' concrete + persistent classes. + +employee-odb.hxx +employee-odb.ixx +employee-odb.cxx +employee.sql + The first three files contain the database support code and the last file + contains the database schema for the employee.hxx header. + + These files are generated by the ODB compiler from employee.hxx using the + following command line: + + odb -d <database> --generate-schema --generate-query employee.hxx + + Where <database> stands for the database system we are using, for example, + 'mysql'. + +database.hxx + Contains the create_database() function which instantiates the concrete + database class corresponding to the database system we are using. + +driver.cxx + Driver for the example. It includes the employee.hxx and employee-odb.hxx + headers to gain access to the persistent classes and their database support + code. It also includes database.hxx for the create_database() function + declaration. + + In main() the driver first calls create_database() to obtain the database + instance. It then persists a number of employee and contractor objects + via their common base (person). The next transaction loads these objects, + also via their common base. Once loaded, the driver calls the print() + virtual function on each of them. Next, the driver changes an employee + from temporary to permanent and updates its state in the database, again + using the base class interface. The driver then queries the database for + all the person objects that have Doe as the last name. The result set of + this query contains a mix of employee and contractor objects. The driver + iterates over this result set and calls the print() virtual function for + each object. Finally, the driver erases the state of the persistent + objects from the database, again using the base class interface. + +To run the example we may first need to create the database schema (for some +database systems, such as SQLite, the schema is embedded into the generated +code which makes this step unnecessary). Using MySQL as an example, this +can be achieved with the following command: + +mysql --user=odb_test --database=odb_test < employee.sql + +Here we use 'odb_test' as the database login and also 'odb_test' as the +database name. + +Once the database schema is ready, we can run the example (using MySQL as +the database): + +./driver --user odb_test --database odb_test |