Analysis Management

[h3ssto]

Principal Goal:
On upload of feature model a number of analyses should be asynchronously triggered. This is realized via calls to a restful API (ddueruem-rest). This service returns a promise/future (uid) which can be polled in the future. Three answers are possible:

• Not finished
• Error
• Finished (returns JSON)

To keep track of started/failed/completed analysis, the backend should maintain a DB table like the following

file_id	analysis_id	triggered	error	result

Analysis Management

An analysis consists of the following information

analysis_id	admin_only	disabled	query

• admin_only: Toggles that analyses are not executed automatically but have to be invoked manually by an admin (requires its own management -> later)
• disabled: Toggles that an analysis is disabled and thus not invoked on upload (needs mangement what should happen with existing data on disable or with unprocessed models on enable -> later)
• query: This is the second part of a ddueruem CLI command

There should be an admin view in the frontend that allows to add/manipulate/remove analysis. Furthermore, it should be possible for an analysis to depend on other analyses to be computed first

---

Original Brainstorming:

doodle_analysis.pdf

[nhoehne]

The following steps need to be taken to fully implement analyses in the backend:

• Edit the class AnalysisResult in ddueruem-web/backend/core/fileupload/models.py to include a field to store the analysis promise.

• Edit the function trigger_all_triggerable_analyses in ddueruem-web/backend/core/fileupload/utils.py to actually trigger the analyses.

• Edit the function check_pending_analysis_results in ddueruem-web/backend/core/fileupload/utils.py to check for pending analysis results and insert them into the database.

  • Figure out what to do when the analysis fails: currently there is a boolean field error and the field result is nullable.

• In ddueruem-web/backend/core/fileupload/viewsets.py the AnalysisViewset doesn't currently allow for the modification of existing analyses (because AnalysisViewset doesn't inherit from mixins.UpdateModelMixin). If modification of existing analyses is required, the following issues should be taken care of:

  • Modifying the dependency list can create loops. The backend should deny any request to modify an analysis that introduced a dependency loop. For a "defense in depth" approach it might also make sense to check for loops in trigger_all_triggerable_analyses?
  • Modifying the query of an analysis should invalidate all corresponding analysis results.