Table of Contents
The diagram above does not show "modifyTimestamp" nor does it show "createTimestamp".
In general, an "code" is used to identify instances of entities in the database. For example, a UUID might be used such as "7cc57be5-ca7b-4229-a00b-084b32a4e1c3". In some cases an existing natual key is already in place and so that attribute is used. An example of this is the "Pkg" entity which is uniquely identified by its attribute "name". Note that the identifier is not the primary key. In all cases, the database primary and foreign keys are artificial numerical identifiers that are supplied by sequences.
A package is a cohesive piece of software or software sub-system for the Haiku operating system. This might for example be an application such as "bepdf" or "armyknife" or a command line tool such as "pari".
Repositories are sources of packages. A repository has a number of repository sources. Each RepositorySource covers an Architecture and each RepositorySource can have a number of Mirrors. One Mirror is a "primary" Mirror for the repository and is where HaikuDepotServer will go to get updated data for this RepositorySource when it needs to. A RepositorySourceMirror is associated with a Country and in this way it is possible to identify a good source of repository data to use dependent on a user's physical location.
The RepositorySource contains an "identifier" field and this string acts as an identifier for the RepositorySource. The actual URLs where repository data can be fetched are found in the RepositorySourceMirror-s. You can find out more about this in the repository section.
Package versions' data is "siloed" between repositories, but some data such as localization, iconography and screenshots are shared. This means that if you have the package "bepdf" made available in more than on repository, that package will share some aspects such as iconography and screenshots.
Some packages are loosely in a relationship with a main package. For example, the package "aspell_devel" is subordinate to "aspell" and "qupzilla_x86" is subordinate to "qupzilla". In such cases, a relationship exists, by naming convention, wherein the subordinate package should take on some of the meta-data of the main package. The system achieves this through the PkgSupplement entity. A PkgSupplement entity instance holds the relationship to icons, screenshots, changelogs and categories and then any related Pkg entity instances relate to that PkgSupplement.
Each time the user changes the Package Supplement (an icon, a screenshot, localization ...) then a record is made as to who changed this. Because the data may change over time a description of the change is captured instead of linking to the actual entity which has changed.
The entry may not be linked to a user in the HDS system because the actual user who made the change might have come from another system altogether. In any case, the field "user_description" provides a description of user who did make the change.
User usage conditions are the terms by which a user is able to use the HDS system. These should be agreed to before the user is able to make use of the system. These are loaded into the database from compile-time resources in the HDS source code and are loaded into the "UserUsageConditions" table. In this way, the compile-time resources act like a migration.