1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
|
This example shows how to declare and use bidirectional one-to-one, one-to-
many, and many-to-many relationships between persistent objects. It also
shows how to work with lazy pointers. All the relationships presented in
this example declare one side as inverse in order to produce canonical
database schema.
The example uses the shared_ptr and weak_ptr smart pointers from TR1 and
requires a C++ compiler with TR1 support or an external TR1 implementation,
such as the one provided by Boost.
The example consists of the following files:
employee.hxx
Header file defining the 'employee', 'employer', 'position', and 'project'
persistent classes as well as the employer-employee (one-to-many),
employee-position (one-to-one), and employee-project (many-to-many)
bidirectional relationships between them.
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 \
--default-pointer std::tr1::shared_ptr employee.hxx
Where <database> stands for the database system we are using, for example,
'mysql'.
The --default-pointer option is used to make TR1 shared_ptr the default
object pointer.
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 creates a number of 'employee', 'employer', 'position',
and 'project' objects, sets the relationships between them, and persists
them in the database. In the next few transactions the driver loads various
objects, then accesses and modifies the relationships between them. Finally,
the driver performs a database query which uses a data member from a related
object in its criterion.
To run the example we first need to create the database schema. 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
|
