Database Fixtures

In RadGrad, "database fixture" (or "DB fixture") refers to a json file that contains definitions for instances of the data model.

For example, settings.development.json contains a field named "databaseRestoreFileName" that specifies a file in the app/private/ directory.

An example of a DB fixture file is 2020-01-24-11-37-22.json. We use this fixture file for development purposes. DB fixtures used for development contain simulated data for users, and generally incomplete data about courses, opportunities, and so forth.

DB fixtures also exist for production deployments of RadGrad. However, such fixtures contain actual student data and so are not committed to GitHub.

RadGrad implements a database dump mechanism to generate DB fixture files based upon the current contents of the database in a running system. The dump command is available to those who login with the administrator account. Those files are named with a timestamp indicating when they were generated.

Snapshot vs. modular DB fixture files

DB fixture files generated by the admin database dump command are "snapshots" of an entire database, and one-and-only-one of them can be loaded into a RadGrad instance. This is because RadGrad throws an error if an attempt is made to define an entity with the same name twice, and virtually all snapshot DB fixtures will contain overlapping definitions.

To simplify testing, RadGrad developers have hand-rolled a set of DB fixture files designed to be loaded in combination with each other. We call these "modular" DB fixture files, and they are located in private/database/modular. Unlike snapshot DB fixture files, the modular DB fixture files defined in this directory do not duplicate any definitions. These files exist in order to simplify testing by allowing a test to load whatever combination of modular DB fixture files are necessary to carry out the tests. For example, OpportunityCollection.methods.app-test.ts loads two modular fixture files: "minimal" and "opportunities".