vengi/docs/Persistence.md

Persistence layer

General

This module manages the persistence layer and provides drivers to talk to the database. Currently the only driver implemented is for postgresql.

The main class for doing database interaction is the DBHandler.

In order to generate models that represent the tables, you can use the databasetool to generate the models from metadata files.

A more high level class to manage updates is the PersistenceMgr. It collects dirty-marked models and performs a mass-delta-update via prepared statements. You should use this for e.g. player updates.

It's always a good idea to check out the unit tests to get an idea of the functionality of those classes.

DBHandler

You have to create the models with the tbl file and generate C++ classes with the databasetool (see existing tables.tbl file CMake integrations. Usually you put your classes into the C++ namespace db. Once you have those models, you can use the generated getters and setters to prepare the model. This can now get send over to the DBHandler. There are methods to insert, update, count, delete or select particular entries from tables via the model values.

Copying the Model class instance is no problem, it's fast. The stuff that is copied is only 32bytes at the moment.

Create (and update) table

_dbHandler->createOrUpdateTable(db::EventModel());

The persistence layer has automatic upgrading and downgrading support for your tables. By defining them in a .tbl file, the system is able to generate the needed ALTER statements to get to your desired state.

Workflow to update a table:

• Edit the tbl file
• Run your build
• Run the application
  • The table, constraint, sequence... is updated to the state that is defined in your code. This allows you to go back and forth in your commits to test things. But keep in mind that removing a column from a table can lead to data loss. Because re-adding it, doesn't remember the previous values of course.

Select by condition

_dbHandler->select(db::EventModel(), persistence::DBConditionOne(), [this] (db::EventModel&& model) {
  [...]
});

Multiple search conditions

const db::DBConditionTestModelEmail emailCond("a@b.c");
const db::DBConditionTestModelName nameCond("Foo Bar");
_dbHandler->select(db::TestModel(), persistence::DBConditionMultiple(true, {&emailCond, &nameCond})), [this] (db::TestModel&& model) {
  [...]
});

PersistenceMgr

This class is responsible to submit chunks for accumulated database updates. If you e.g. collect an item and soon after collect another one, this class will sum the items up and only generate one sql statement, instead of two.

Databasetool

Table descriptions for the databasetool

The databasetool binary will generate model files for the table definitions given in *.tbl files. You can specify the fields, the constraints and set an operator for dealing with conflict states (more about that later).

To add a new *.tbl file to a module and automatically generate code for that table definition, you have to add the following after your cmake add_library(${LIB} ${SRCS}) call:

generate_db_models(${LIB} ${CMAKE_CURRENT_SOURCE_DIR}/tables.tbl ExampleModels.h)

ExampleModels.h specifies a single header where all generated table models are put into.

The generated models can be used with the DBHandler from the persistence module.

Example

If no classname is specified, the table name will be used with Model as postfix.

Table user will be generated as UserModel class, if no other classname was specified

All models will be put into a db namespace - even if you specify your own namespace. For more details, see the parameter description below.

table <TABLENAME> {
  classname <STRING> (overrides the automatically determined name)
  namespace <STRING> (c++ namespace where the class is put into)
  schema <STRING> (default is public)
  field <FIELDNAME> {
    type <FIELDTYPE> (default: string)
    notnull (optional)
    length <LENGTH> (optional)
    operator <OPERATOR> (default: set)
    lowercase (optional)
    default <DEFAULTVALUE> (optional)
  }
  constraints {
    <FIELDNAME> unique
    <FIELDNAME> index
    <FIELDNAME> primarykey
    <FIELDNAME2> primarykey
    <FIELDNAME> autoincrement
    (<FIELD1>, <FIELD2>) unique
    <FIELDNAME> foreignkey <FOREIGNTABLE> <FOREIGNFIELD>
  }
}

table

A definition starts with table <TABLENAME>. The body is enclosed by { and }.

classname

This can be used to override the auto generated class name. The auto generated class name is generated from the table name converted to UpperCamelCase. This converts a table name like my_table to MyTable or mytable to Mytable.

namespace

You specify a namespace in your table definition that is called mynamespace. The table is called MyTable. The resulting c++ class will live in mynamespace::db::MyTable. If you omit the namespace setting in your table definition, the class will live in db::MyTable.

schema

Specifies the schema name that should be used for the table.

field

A field describes a table column, the name, the type and so on. This block is enclosed by { and }.

default

The default value for the field.

length

Specifies the optional length of the field.

notnull

If this is specified, the field may not be null.

operator

The operator is taken into account when you execute an insert or update statement and hit a unique key violation.

This can e.g. be used to increase or decrease points for particular keys. The first time you normally perform an insert - and the following times you will hit a key violation and thus perform the insert or update with the operator specified. The default operator is set. See a full list of valid operators below.

Valid operators

• set
• add
• subtract

lowercase

Convert a string value to lowercase before entering it into the database. This may not be set for password types of course.

type

Valid field types

• password
• string
• text
• int
• long
• timestamp
• boolean
• short
• byte
• blob

constraints

Here you can specify foreign key constraints, auto increment values and so on. This block is enclosed by { and }.

See the example above for a list of supported constraints.

Other notable features

• Timestamps are handled in UTC.
• When using int or short as a field type, there is also a setter configured that accepts enums.