|
|
|
@ -775,7 +775,7 @@ and email are short strings, age is an integer. Considering this, relational
|
|
|
|
|
databases or formatted plain files (CSV for example) fits best for them.
|
|
|
|
|
However, the data often have to support find operation, so they have to be
|
|
|
|
|
sorted and allow random access for resolving cross references. Also, addition a
|
|
|
|
|
deletion of entries should take reasonable time (at most logaritmic time
|
|
|
|
|
deletion of entries should take reasonable time (at most logarithmic time
|
|
|
|
|
complexity to number of saved values). This practically excludes plain files, so
|
|
|
|
|
relational database is used instead.
|
|
|
|
|
|
|
|
|
@ -1459,7 +1459,7 @@ David Grudl -- and we were already familiar with the patterns used in this
|
|
|
|
|
framework, such as dependency injection, authentication, routing. These concepts
|
|
|
|
|
are useful even when developing a REST application, which might be a surprise
|
|
|
|
|
considering that Nette focuses on "traditional" web applications. There is also
|
|
|
|
|
a Nette extension which makes integartion of Doctrine 2 very straightforward.
|
|
|
|
|
a Nette extension which makes integration of Doctrine 2 very straightforward.
|
|
|
|
|
|
|
|
|
|
#### Request handling
|
|
|
|
|
|
|
|
|
@ -1522,7 +1522,7 @@ fileserver to create an archive of the solution files.
|
|
|
|
|
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
|
|
|
|
|
example, these steps are parsing of the results, computation of score or saving
|
|
|
|
|
structured data into database. There are two main possibilities of loading:
|
|
|
|
|
|
|
|
|
|
- immediately
|
|
|
|
@ -1538,14 +1538,14 @@ 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
|
|
|
|
|
author (administrator 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.
|
|
|
|
|
we will rethink this decision.
|
|
|
|
|
|
|
|
|
|
#### Backend management
|
|
|
|
|
|
|
|
|
|