Details
-
Bug
-
Resolution: Unresolved
-
None
-
None
-
Critical
-
Empty show more show less
Description
The current worker dependency table is very confusing, since a tree structure is stored as a 2d list. Maintenance is purley possible, its not possible to find missing nodes in the dependency tree.
Also some workers used in many places are named wrong.
Todos:
- merge editor_Segment_Quality_ImportWorker and editor_Segment_Quality_OperationWorker
- both are doing the same, in import worker the processingMode is hardcoded, but that can be done on invocation
- in operationWorker task locking is done, what is not needed in import context, can also be controlled by param on invocation (or by evaluating task state = import do no locking/unlocking then)
- fix TRANSLATE-3374
- current editor_Models_Import_Worker_SetTaskToOpen is used in to many contexts
- the worker basically does how its named - it opens the task after some other actions are performed
- for operations the task opening can be done in the end operation step
- for import
- we should consider to rename the worker to a TaskImportSuccess → which then opens the task after import
- and rename editor_Models_Import_Worker_FinalStep to TaskImportFinish
- This names are more obvious in what they do instead just SetTaskToOpen
- check if there are remaining other usages of SetTaskToOpen in the php code
- generate the content of the LEK_worker_dependency table automatically by maintaining and defining the dependencies / blocks in the PHP code
- define for workers a dependency (isBlockedBy) and a block list, so that we can deal both directions
- This has the benefit that the definition is at the place where it is used
- Only direct deps must be defined, the whole dep tree is then generated automatically into the DB
- when applying the current DB based deps to PHP code they must be revalidated (for example current chaos in export, unclear deps in visual workers) and no redundant but only direct dependencies must be added to the php code
- generation should be invoked on installation updating like database:update
- for generation all php files with class statements in it must be imported (or can the composer class map be used?)
- All recursive children of the abstract worker class must be considered, and the deps and blocks must be loaded from the class
- Out of that the list in the DB can be updated
- For worker startup nothing changes
Attachments
Issue Links
- blocks
-
TRANSLATE-2217 List refactoring and code maintenance needs in translate5
- Selected for dev
- is blocked by
-
TRANSLATE-3374 Okapi import may block okapi export
- Open
- relates to
-
TRANSLATE-3448 Missing worker dependencies
- Done
-
TRANSLATE-3454 Analysis runs through although t5memories are in state of reorganisation
- Done