TMSS-917: added rationale why we cannot implement a proper constraint.

SAS/TMSS/backend/src/tmss/tmssapp/models/scheduling.py

@@ -160,6 +160,13 @@ class Subtask(BasicCommon, ProjectPropertyMixin, TemplateSchemaMixin):
     path_to_project = 'task_blueprints__scheduling_unit_blueprint__draft__scheduling_set__project'
 
     # TODO: find a way to enforce that only one subtask per TaskBlueprint has primary==True. The ManyToManyField makes that dificult. RawSQL? CheckConstraint and Q?
+    # JS 2021-08-24: Had a chat with Joern about the "problem" of the many-to-many relation between tasks and subtasks.
+    # It will be too much work (for now) to introduce either the old normal foreignkey relation where 1 task has 1-n subtasks.
+    # It will also be too much work to make a non-race-condition check on 1 primary subtask per parent task.
+    # There is a race condition because you first need to create both the task and subtask and then make the link. In between these steps there are forbidden possibilities.
+    # It is also quircky to introduce a foreignkey relation between task and subtask like 'primary_subtask' or 'is_primary_subtask_of' besides the existing task-subtask many-to-many-relation.
+    # So, we decided that for now we accept that we just cannot enforce a single-primary-subtask-per-task at database level.
+    # We think this is acceptable, because only our django tmss application creates subtasks (that's us!), so we are in control of setting the correct subtask as the one-and-only primary subtask.
     # class Meta(BasicCommon.Meta):
     #     constraints = [UniqueConstraint(fields=['primary', 'task_blueprints'], name='subtask_unique_primary_subtask')]