Project

General

Profile

Feature #8580

Redundant data is stored in job archives for progress

Added by Evgeny Novikov over 2 years ago. Updated 3 months ago.

Status:
Rejected
Priority:
High
Assignee:
-
Category:
Bridge
Target version:
-
Start date:
11/19/2017
Due date:
% Done:

0%

Estimated time:
Published in build:

Description

In addition to a normal progress data I saw also a configuration and a priority in field "progress" in file "job.json".

History

#1

Updated by Ilja Zakharov over 2 years ago

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.

#2

Updated by Vladimir Gratinskiy over 2 years ago

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.

#3

Updated by Evgeny Novikov over 2 years ago

  • 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".

#4

Updated by Vladimir Gratinskiy 6 months ago

  • Status changed from New to Feedback

Does this problem still exist?

#5

Updated by Evgeny Novikov 3 months ago

  • Assignee deleted (Vladimir Gratinskiy)
  • Status changed from Feedback to Rejected

It exists, but I do not think that it is important at all.

Also available in: Atom PDF