Feature #8580
closed
Redundant data is stored in job archives for progress
Added by Evgeny Novikov over 6 years ago.
Updated about 4 years ago.
Description
In addition to a normal progress data I saw also a configuration and a priority in field "progress" in file "job.json".
Also when I upload a solved job with the progress caclulated I see redundant "Total tasks to be solved: Estimating the number" but no other information about the progress.
Now for uploaded jobs I have to show start and finish decision dates. Earlier it was missed (all jobs on ldvstore). To show this data I need to save it to archive and then, after job uploading, to DB. There is model "SolvingProgress" where these dates are saved. But for creating model I need also other fields that can't be null. So all fields for this model are saved in "progress". It is:
[priority, scheduler, start_date, finish_date, tasks_total, tasks_pending, tasks_processing, tasks_finished, tasks_error, tasks_cancelled, solutions, error, configuration]
Ilja Zakharov wrote:
Also when I upload a solved job with the progress caclulated I see redundant "Total tasks to be solved: Estimating the number" but no other information about the progress.
I'll check what's wrong, but it is another issue. Send me archive with such job.
- Tracker changed from Bug to Feature
- Priority changed from Immediate to High
- Target version deleted (
1.0)
Vladimir Gratinskiy wrote:
Now for uploaded jobs I have to show start and finish decision dates. Earlier it was missed (all jobs on ldvstore). To show this data I need to save it to archive and then, after job uploading, to DB. There is model "SolvingProgress" where these dates are saved. But for creating model I need also other fields that can't be null. So all fields for this model are saved in "progress". It is:
[priority, scheduler, start_date, finish_date, tasks_total, tasks_pending, tasks_processing, tasks_finished, tasks_error, tasks_cancelled, solutions, error, configuration]
I understand that this isn't a bug but a minor refactoring. It looks like a bit incorrect design, if you need to transfer useless data in such the way. Perhaps you can split data and corresponding models so that just really necessary values will be downloaded/uploaded without model requirements. Moreover, it should allow to avoid duplicates. For instance, it seems that the same configuration is stored for progress and in directory "Configurations".
- Status changed from New to Feedback
Does this problem still exist?
- Status changed from Feedback to Rejected
- Assignee deleted (
Vladimir Gratinskiy)
It exists, but I do not think that it is important at all.
Also available in: Atom
PDF