Updating Your Data Mining Queries for Beaker 23¶
New installation database table¶
This release adds a new database table, installation, which records each new installation of a distro on a system. The database upgrade process will populate this table with rows for all existing recipes. From this release onwards Beaker will create a new row in this table every time a system is provisioned, either for a recipe or manually (for example, on the system page).
This new table consolidates some existing fields that were previously spread across several different tables. If you are running SQL queries against the Beaker database directly, your queries may need to be updated. The schema changes are described in detail below.
The four timestamp columns on the recipe_resource table for recording installation progress (rebooted, install_started, install_finished, and postinstall_finished) have been moved to the new installation table. You can join through the recipe table on installation.recipe_id, for example:
SELECT ..., installation.rebooted, ...
FROM recipe_resource
INNER JOIN recipe ON recipe_resource.recipe_id = recipe.id
INNER JOIN installation ON installation.recipe_id = recipe.id
...
Similarly, the rendered_kickstart_id column on the recipe table has been moved to installation.
On the command_queue table, the distro_tree_id and kernel_options columns are no longer used. Instead, new rows in command_queue are associated with an installation through the installation_id column and the distro tree and kernel options are stored there instead. Note that existing rows in command_queue may not have an associated installation, so your query should fall back to using command_queue.kernel_options if it needs to consider older rows. For example:
SELECT ...,
COALESCE(installation.kernel_options, command_queue.kernel_options),
...
FROM activity
INNER JOIN command_queue ON activity.id = command_queue.id
LEFT JOIN installation ON command_queue.installation_id = installation.id
WHERE activity.action = 'configure_netboot'
...