Creating the Table Objects

serial_table<movie> movies(db, "movies", &movie::id);
serial_table<cinema> cinemas(db, "cinemas", &cinema::id);
serial_table<screen> screens(db, "screens", &screen::id);

These definitions create three objects representing tables. The actual SQL tables aren't being created yet. In fact these constructors don't communicate with the DBMS at all; they just collect details for later.

The template parameter (e.g. movie) gives the table's value type. This is the C++ type that each complete row of the table represents.

The three constructor arguments are:

The database on which the table will reside. (Either brand of database is acceptable; what we pass to the constructor is an abstract interface that they each implement.)
The table's SQL name.
The primary key within the value type (given in C++ style as a pointer-to-data-member).

Every table has a value mapper, which tells quince exactly how the table's value type should be represented in this particular table. The table constructor builds this, using predefined mapper classes for float, std::string etc. that are appropriate to the given database.

In this example we're constructing serial_tables rather than tables. I use the noun “table”, in normal font, for both, but serial_tables and tables differ from each other as follows:

In a serial_table, a value is automatically assigned to the primary key whenever a record is inserted (so it must be a serial).
In a table, the primary key must be present in a record before it is inserted, and then it is copied into the table like any other member (regardless of whether it is a serial or not).

Our code uses the simplest form of the constructor, which is often all you need, but other forms are available also.

PostgreSQL only: When we constructed db, we specified that test is the default schema. So when we create tables without mentioning a schema (as we do here), they go into the schema test -- with quince creating it if necessary.

Creating the Table Objects

Remarks