Toaster database

ORM diagram

Toaster Uses Django and it's ORM for database interaction.

The database table/model definitions can be found in the orm/models.py file. We also have additional models defined for the build controller, these are generally the 'behind the scenes' way in which we translate toaster information into the build controller process. This page is a high level look at the database design and how it is used.

Categories of data in Toaster

Build data

Build data is Layers, Layer_Versions, Recipes, Machines, Packages, Dependencies and all other objects that are output by running a build of a recipe. Once it is created it is never edited or updated. Unless deleted by the user.

Configuration data

Configuration data is data which is provided by Toaster to configure an openembedded based project in Toaster, like Build data this is stored as Layers, Layer_Versions, Recipes and Machines etc. The configuration data can be produced by fetching it from the Layer Index (the toaster start up script attempts to do this for you at first run) from importing information from the toasterconf.json file, importing Layer definitions into Projects via the Import layer page and also from running a build.

Project data

Some data is designated project specific, such as user imported Layer, CustomImageRecipe, Project variables and Builds.

Top level models

There are many intermediate tables in Toaster's database, see diagram. Below are the most top level models on which everything else depends.

Layer and Layer_Version

A Layer_Version is the model in which most other models relate to in Toaster. Every Layer_Version object belongs to a Layer object which contains the common metadata for each 'version' or revision of the Layer.

An example would be that we have a Layer called 'meta-openembedded' which has 3 Layer_Versions; one Layer_Version which is set to the release 'dizzy' one on 'fido' and one on 'master' (in most cases these correspond to git branch names)

Layer 1 - N Layer_Version 1 - N Recipe 1 - N Packages

Recipe

Recipes contain the information about a collection or particular piece of software. This can be the name, version and description and any distribution packages are created by the Recipe.

An example would be a recipe called myrecipe version 1.2 which produces 3 Packages myrecipe-dev, myrecipe-dbg and myrecipe. Recipes are the objects which get built by BitBake.

Recipe N - 1 Layer_Version

Recipe 1 - N Package

CustomImageRecipe

This is a special kind of Recipe which has two additional fields; base_recipe and project. base_recipe is the Recipe in which the Custom recipe has been based on and will translate to the 'required' recipe to inherit recipe metadata from and project because this custom recipe belongs to a certain project that has been created.

Package

A Package is the representation of distribution packages produced by a Recipe when it has been built. Package data is almost always Build data since we don't know about packages until they have been produced. The exception is when the package data is used as configuration data to Customise a recipe by adding and removing known packages.

Package N - 1 Recipe

Target

When you build a Target object is created which contains one or more Recipe names, Build object for the build data to go into and the Task that you're asking bitbake to do (default is build the recipe).

Build

The Build model contains the metadata for reporting information about a Build. The includes when the Build started and stopped some of the configuration of the Build such as the Machine set.

What running a Build affects

When you've configured your project in Toaster (using configuration data) and hit build on a Recipe two main things happen.

1. Update or create the Recipe and Layer_Version in Toaster with any new information that we gathered by building it

When a recipe is built we can update the configuration information in Toaster to be more accurate. e.g. if we have newer information than provided by the Layer index or if we're building a recipe in an imported layer for the first time we can update that Layer_Version to say what Recipes are in it.

2. Make a copy of the Recipe(s) built and the Layer_Version(s) in the project at build time

Copying creates a snapshot of that configuration data for the purposes of the build history. It also allows us to compartmentalise the build specific data e.g. what version the recipe was on, what the git checkout was at the time of build, the Machine set which may affect the recipes and packages etc

The build property for these copied Layer_Versions is set. When this is set the objects down the relational chain (Layer_Version 1 - N Recipe 1 - N Packages) are considered part of the "build data" and should never be changed or edited after this point.