Skip to content

WorkerConfigurationField model

https://redmine.teklia.com/issues/10348

User-configurable parameters on workers were originally an optional layer to make some worker configurations easier, but they are now used everywhere, with workers having far more complex configurations, and the current configuration system is getting harder to understand for users and worker developers and to maintain for Arkindex developers. To start replacing them with a new configuration format and make them easier to work with in the API, we need a new model to store the available configuration fields.

A new arkindex.process.models.WorkerConfigurationField model should be added with the following fields:

  • id: UUID, primary key, defaults to uuid4, not editable in the Django admin.
  • worker_version: Non-nullable foreign key to WorkerVersion. Deleting a worker version should cascade to all fields.
  • parent: Nullable foreign key to self, with children as the related name, defaulting to None. Used for group fields, which contain other fields as their children. Deleting should do nothing, as this otherwise would make multiple unnecessary queries during worker version deletion.
  • key: Non-nullable CharField, up to 250 characters. This will be the key sent to a task when it retrieves its configuration.
  • display_name: Non-nullable CharField, up to 250 characters. Human-readable name of this field.
  • help_text: Non-nullable TextField defaulting to an empty string. A longer description of the field.
  • type: Non-nullable EnumField for the type of the field, from a new WorkerConfigurationFieldType enum:
    • bool
    • int
    • float
    • string
    • text
    • dict
    • group
    • element_type
    • secret
    • worker_version
    • model
  • many: Non-nullable BooleanField defaulting to False. This turns the field into a list, an equivalent of many=True from DRF.
  • default: Non-nullable JSONField for a default value for this field, defaulting to Value(None, JSONField()). On non-editable fields, this is the fixed value.
    We actually want this field to be nullable, but there are two definitions of a null for JSON fields, in SQL NULL and in JSON 'null'::jsonb. It's easier to exclude the SQL NULL.
  • required: Non-nullable BooleanField defaulting to False. Whether this field has to be set to make a valid configuration. Has no effect on non-editable fields.
  • editable: Non-nullable BooleanField defaulting to True. Whether users can edit this field, or if it is a constant.
  • choices: Nullable array of strings, for the choices allowed in an enum field, defaulting to None.
  • position: Non-nullable PositiveIntegerField with no default value, for the position of the field within this configuration.

Two unique constraints are necessary:

  • (worker_version, key, parent) should be unique with nulls being distinct, to require unique keys within the same configuration.
  • (worker_version, position) should be unique, to make sure we do not mess up the ordering of fields within a configuration.

Some check constraints should also be added:

  • choices cannot be an empty array. It can only be null or a non-empty array.
  • enum fields must have choices set, and other fields cannot have choices set.
  • default cannot be 'null'::jsonb when editable is False.

A new Django admin page should allow a completely read-only view over the configuration fields. It should be possible to search by key and to filter by worker. The list shows the ID, worker version, key, display name and type, and the details for each field shows everything.