Related to the feature #1142 that was not implemented correctly.
The GET /execution-plans must return unique execution plans, and the AQL query should start with scanning executionPlan collection respectively. The following comment from the ExecutionPlanRepositoryImpl.scala:122 is misleading and is likely incorrect:
// cannot use:
// FOR execPlan IN executionPlan
// FOR prog IN 1 OUTBOUND execPlan progressOf
// because CURRENT's context would be `progress`, not `executionPlan`Plus, the /execution-plans REST endpoint should accept more GET parameters to allow for search & filter similarly to /execution-events. At a minimum it should accept searchTerm, append and the label parameters.
Related to the feature #1142 that was not implemented correctly.
The
GET /execution-plansmust return unique execution plans, and the AQL query should start with scanningexecutionPlancollection respectively. The following comment from theExecutionPlanRepositoryImpl.scala:122is misleading and is likely incorrect:Plus, the
/execution-plansREST endpoint should accept more GET parameters to allow for search & filter similarly to/execution-events. At a minimum it should acceptsearchTerm,appendand thelabelparameters.