Skip to content

Separate Problem object from its testdata #2422

@kiritofeng

Description

@kiritofeng

There are instances of problems being cloned (primarily for teaching purposes) where only minor adjustments are made to the problem (e.g. minor changes to the statement, changes to TL/ML, changes to allowed languages, etc), however, these require the test data to be cloned as well.

I propose renaming the current Problem object to ProblemInstance, and creating a new ProblemManager object that is responsible for managing the test data:

  • The ProblemInstance object would hold all of the current fields of Problem, but no longer be responsible for managing test data, instead it will have a ProblemManager ForeignKey
  • The ProblemManager will have a code field, which is unique among all ProblemManager objects
  • The problem OneToOne field in ProblemData will be changed to a ProblemManager.

When creating a problem, an option should be made available to select the desired ProblemManager, or to create a new one (with the same code as the ProblemInstance). When cloning a problem, an option should be given to also clone the test data, which corresponds to copying the ForeignKey of the ProblemManager of the problem being cloned.

When a problem's code is changed, if the associated ProblemManager shares the same code as the problem, its code should also be updated. This should ensure the code of a ProblemManager is one of the codes belonging to an assigned ProblemInstance object, modulo DB tampering.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions