From 90eff61aad9b12ab2f864adf295bee0d439ab5e1 Mon Sep 17 00:00:00 2001 From: Petr Stefan Date: Tue, 10 Jan 2017 23:01:59 +0100 Subject: [PATCH] Solution loading --- Rewritten-docs.md | 36 +++++++++++++++++++++++++++++------- 1 file changed, 29 insertions(+), 7 deletions(-) diff --git a/Rewritten-docs.md b/Rewritten-docs.md index 44c347f..28ed9bd 100644 --- a/Rewritten-docs.md +++ b/Rewritten-docs.md @@ -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