Solution loading

master
Petr Stefan 8 years ago
parent cd071f1974
commit 90eff61aad

@ -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 application is also straightforward, thanks to its dependency injection
container implementation. 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: 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 permission handling, roles, etc.
@todo: on demand loading of students submission, in-time loading of every other submission, why
#### Backend management #### Backend management
Considering the fact that we have backend as a separate component which has no Considering the fact that we have backend as a separate component which has no

Loading…
Cancel
Save