Changing the Core Models

When adding new features, it may be necessary to add new information to the core classes in core.py: Dagobah, Job, and Task. There are a few places in which you will need to perform your changes. Unfortunately, each of these changes are slightly different than the others, so it was decided that it would be overly complex to abstract out all the differences in the code base itself. Rather than consolidating the changes through a complex config object, the steps are documented here to assist you. You can see our original discussion on this topic here.

Please consider these steps as guidelines rather than an exhaustive list; the best way to make sure your changes work correctly is to implement solid tests.

1. Initialize new_var to its starting value in the class's constructor. If new_var does not have a meaningful starting value, initialize it to None.

2. If necessary, create a setter for new_var similar to Task.set_soft_timeout.

3. If new_var can be set when the class is constructed, apply this change to the constructor. By convention, optional constructor arguments are passed around methods as **kwargs. You should therefore define new_var as a kwarg in the constructor.

4. Update any relevant API calls in daemon/api.py, or creation/updating methods in core.py, to consider new_var.

5. If new_var should be permanently stored in the backend or made available to the frontend, for example a Task's soft timeout or a Job's name, do the following:

   1. Add new_var to the _serialize method on its class.
   2. Add new_var to all available backends, using the existing code as a guide.
   3. Add a new Alembic revision to handle this migration for SQL-based backends. See SQL Migrations using Alembic.

6. Test whatever you can because it makes you awesome.