|
|
|
@ -3193,7 +3193,7 @@ this "concrete" assignment, such as the name, version and a private description.
|
|
|
|
|
|
|
|
|
|
Some exercise descriptions need to be translated into multiple languages.
|
|
|
|
|
Because of this, the `Exercise` entity is associated with the
|
|
|
|
|
`LocalizedAssignment` entity, one for each translation of the text.
|
|
|
|
|
`LocalizedText` entity, one for each translation of the text.
|
|
|
|
|
|
|
|
|
|
An exercise can support multiple programming runtime environments. These
|
|
|
|
|
environments are represented by `RuntimeEnvironment` entities. Apart from a name
|
|
|
|
@ -3202,7 +3202,7 @@ is being used. There is also a list of extensions that is used for detecting
|
|
|
|
|
which environment should be used for student submissions.
|
|
|
|
|
|
|
|
|
|
`RuntimeEnvironment` entities are not linked directly to exercises. Instead,
|
|
|
|
|
the `Exercise` entity has an M:N relation with the `SolutionRuntimeConfig`,
|
|
|
|
|
the `Exercise` entity has an M:N relation with the `RuntimeConfig` entity,
|
|
|
|
|
which is associated with `RuntimeEnvironment`. It also contains a path to a job
|
|
|
|
|
configuration file template that will be used to create a job configuration file
|
|
|
|
|
for the worker that processes solutions of the exercise.
|
|
|
|
@ -3222,6 +3222,10 @@ entities can have multiple `ReferenceSolutionEvaluation` entities associated
|
|
|
|
|
with them that link to evaluation results (`SolutionEvaluation` entity). Details
|
|
|
|
|
of this structure will be described in the section about student solutions.
|
|
|
|
|
|
|
|
|
|
Source codes of the reference solutions can be accessed using the `Solution`
|
|
|
|
|
entity associated with `ReferenceSolution`. This entity is also used for student
|
|
|
|
|
submissions.
|
|
|
|
|
|
|
|
|
|
#### Assignments
|
|
|
|
|
|
|
|
|
|
The `Assignment` entity is created from an `Exercise` entity when an exercise is
|
|
|
|
@ -3230,16 +3234,51 @@ reference documentation for a detailed overview). Additional information such as
|
|
|
|
|
deadlines or point values for individual tests is also configured for the
|
|
|
|
|
assignment and not for an exercise.
|
|
|
|
|
|
|
|
|
|
Assignments can also have their own `LocalizedAssignment` entities. If the
|
|
|
|
|
Assignments can also have their own `LocalizedText` entities. If the
|
|
|
|
|
assignment texts are not changed, they are shared between the exercise and its
|
|
|
|
|
assignment.
|
|
|
|
|
|
|
|
|
|
Runtime configurations can be also changed for the assignment. This way, a
|
|
|
|
|
supervisor can for example alter the resource limits for the tests.
|
|
|
|
|
supervisor can for example alter the resource limits for the tests. They could
|
|
|
|
|
also alter the way submissions are evaluated, which is discouraged.
|
|
|
|
|
|
|
|
|
|
#### Student Solutions
|
|
|
|
|
|
|
|
|
|
#### Comment threads
|
|
|
|
|
Solutions submitted by students are represented by the `Submission` entity. It
|
|
|
|
|
contains data such as when and by whom was the solution submitted. There is also
|
|
|
|
|
a timestamp, a note for the supervisor and an url of the location where
|
|
|
|
|
evaluation results should be stored.
|
|
|
|
|
|
|
|
|
|
However, the most important part of a submission are the source files. These are
|
|
|
|
|
stored using the `SolutionFile` entity and they can be accessed through the
|
|
|
|
|
`Solution` entity, which is associated with `Submission`.
|
|
|
|
|
|
|
|
|
|
When the evaluation is finished, the results are stored using the
|
|
|
|
|
`SolutionEvaluation` entity. This entity can have multiple `TestResult` entities
|
|
|
|
|
associated with it, which describe the result of a test and also contain
|
|
|
|
|
additional information for failing tests (such as which limits were exceeded).
|
|
|
|
|
Every `TestResult` can contain multiple `TaskResult` entities that provide
|
|
|
|
|
details about the results of individual tasks. This reflects the fact that
|
|
|
|
|
"tests" are just logical groups of tasks.
|
|
|
|
|
|
|
|
|
|
#### Comment Threads
|
|
|
|
|
|
|
|
|
|
The `Comment` entity contains the author of the comment, a date and the text of
|
|
|
|
|
the comment. In addition to this, there is a `CommentThread` entity associated
|
|
|
|
|
with it that groups comments on a single entity (such as a student submission).
|
|
|
|
|
This enables easily adding support for comments to various entities -- it is
|
|
|
|
|
enough to add an association with the `CommentThread` entity. An even simpler
|
|
|
|
|
way is to just use the identifier of the commented entity as the identifier of
|
|
|
|
|
the comment thread, which is how submission comments are implemented.
|
|
|
|
|
|
|
|
|
|
#### Uploaded Files
|
|
|
|
|
|
|
|
|
|
Uploaded files are stored directly on the filesystem instead of in the database.
|
|
|
|
|
The `UploadedFile` entity is used to store their metadata. This entity is
|
|
|
|
|
extended by `SolutionFile` and `ExerciseFile` using the Single Table Inheritance
|
|
|
|
|
pattern provided by Doctrine. Thanks to this, we can access all files uploaded
|
|
|
|
|
on the API through the same repository while also having data related to e.g.,
|
|
|
|
|
supplementary exercise files present only in related objects.
|
|
|
|
|
|
|
|
|
|
### Request Handling
|
|
|
|
|
|
|
|
|
|