|
|
|
@ -1485,18 +1485,40 @@ thanks to the simple authentication flow. Replacing these services in a Nette
|
|
|
|
|
application is also straightforward, thanks to its dependency injection
|
|
|
|
|
container implementation.
|
|
|
|
|
|
|
|
|
|
@todo: mail reports - to users, admins
|
|
|
|
|
#### Solution loading
|
|
|
|
|
|
|
|
|
|
When a solution evaluation on backend is finished, results are saved to
|
|
|
|
|
fileserver and API is notified by broker about this state. Then some further
|
|
|
|
|
steps needs to be done before the results can be presented to users. For
|
|
|
|
|
example, these steps are parsing of the results, computating score or saving
|
|
|
|
|
structured data into database. There are two main possibilities of loading:
|
|
|
|
|
|
|
|
|
|
- immediately
|
|
|
|
|
- on demand
|
|
|
|
|
|
|
|
|
|
They are almost equal, none of them provides any kind of big advantage. Loading
|
|
|
|
|
solutions immediately is better, because fetching results from client for the
|
|
|
|
|
first time can be a bit faster. On the other hand, loading them on demand when
|
|
|
|
|
they are requested for the first time can save some resources when the solution
|
|
|
|
|
results are not important and no one is interested in them.
|
|
|
|
|
|
|
|
|
|
From this choice, we picked up lazy loading when the results are requested.
|
|
|
|
|
However, concept of asynchronous jobs is then introduced. This type of job is
|
|
|
|
|
useful for batch submitting of jobs, for example rerunning jobs which failed on
|
|
|
|
|
worker hardware issue. These jobs are typically submitted by different user than
|
|
|
|
|
author (administator for example), so original authors should be notified. In
|
|
|
|
|
this case it is more reasonable to load the results immediately and optionally
|
|
|
|
|
send them with the notification. Exactly this is also done, special asynchronous
|
|
|
|
|
jobs are loaded immediately with email notification to the original job author.
|
|
|
|
|
|
|
|
|
|
From a short time distance it seems that immediate loading of all jobs could
|
|
|
|
|
simplify loading code and has no major drawbacks. In the next version of ReCodEx
|
|
|
|
|
we will rethink this decission.
|
|
|
|
|
|
|
|
|
|
@todo: what files are stored in api, why there are duplicates among api and fileserver
|
|
|
|
|
|
|
|
|
|
@todo: groups and hierarchy, describe arbitrary nesting which should be possible
|
|
|
|
|
within instance and how it is implemented and how it could be implemented
|
|
|
|
|
(describe only implementation if it is something what to say)
|
|
|
|
|
|
|
|
|
|
@todo permission handling, roles, etc.
|
|
|
|
|
|
|
|
|
|
@todo: on demand loading of students submission, in-time loading of every other submission, why
|
|
|
|
|
|
|
|
|
|
#### Backend management
|
|
|
|
|
|
|
|
|
|
Considering the fact that we have backend as a separate component which has no
|
|
|
|
|