From 0d8080449633e6b5ebc075001ac64cf88112ee69 Mon Sep 17 00:00:00 2001 From: Marco Del Tufo <marco.deltufo@exact-lab.it> Date: Tue, 1 Aug 2023 10:21:27 +0000 Subject: [PATCH] Update maintenance-tasks.md --- .../advanced-features/maintenance-tasks.md | 19 +++---------------- 1 file changed, 3 insertions(+), 16 deletions(-) diff --git a/docs/system-admin-documentation/advanced-features/maintenance-tasks.md b/docs/system-admin-documentation/advanced-features/maintenance-tasks.md index 4791a000ec5..eb3b3ec232c 100644 --- a/docs/system-admin-documentation/advanced-features/maintenance-tasks.md +++ b/docs/system-admin-documentation/advanced-features/maintenance-tasks.md @@ -207,9 +207,7 @@ where <entity kind> is either EXPERIMENT, SAMPLE or DATA_SET (Materials are **Description**: Deletes data sets which have been deleted on AS. -If this task isn't configured neither in service.properties nor as a -core plugin it will be established automatically by using default -configuration and running every 5 minutes. +> :information_source: If this task isn't configured neither in service.properties nor as a core plugin it will be established automatically by using default configuration and running every 5 minutes. **Configuration**: @@ -796,11 +794,7 @@ Some rules: - Material type codes and property type codes have to be in upper case. -If you put a foreign key constraint on the material code of one of the -material properties, you need to define the constraint checking as -DEFERRED in order to not get a constraint violation. The reason is that -this task will *not* order the `INSERT` statements by its dependencies, -but in alphabetical order. +> :warning: **If you put a foreign key constraint on the material code of one of the material properties, you need to define the constraint checking as DEFERRED in order to not get a constraint violation. The reason is that this task will *not* order the `INSERT` statements by its dependencies, but in alphabetical order.** ### UsageReportingTask @@ -1069,14 +1063,7 @@ The data sets are processed in the inverse order they are registered. Only a maximum number of data sets are processed in one run. This is specified by `chunk-size`. -Under normal circumstances this maintenance task is **never** needed, -because the content of a physical data set is **never** changed by -openBIS itself. - -Only in the rare cases that the content of physical data sets have to be -changed this maintenance task allows to refresh the file meta data in -the pathinfo database. - +> :warning: **Under normal circumstances this maintenance task is never needed, because the content of a physical data set is **never** changed by openBIS itself.<br /><br />Only in the rare cases that the content of physical data sets have to be changed this maintenance task allows to refresh the file meta data in the pathinfo database.** **Configuration**: -- GitLab