V3 API enable should check dependencies
- Vorherrschende Sprache
- Scala
- Sterne
- 33
- Forks
- 16
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Beschreibung
## Background & Feature
Originating in https://github.com/AbsaOSS/enceladus/pull/2055#discussion_r870068092, the idea is that when enabling an entity, all its dependencies should be checked to be enabled as well.
## Feature
Since V3 API considers entity disable/enable as a single state (going forward), dependencies of all entity versions must be checked.
## Example
`DatasetA` v1 has `schemaA` v2 and mapping CR that is tied to `mappingTableA` v6 and also defines `propertyDefinionA`
`DatasetA v2 has `schemaB` v3, no mapping CR and defines `propertyDefintionB`.
`DatasetA` is disabled.
When trying to (re)enable it, `schemaA` in v2, `schemaB` v3, `mappingTableA` v6, `propertyDefintionA|B` (all versions) must be check to be enabled in order for DatasetA to be correctly enabled.
## Proposed Solution [Optional]
Solution Ideas:
1. Utilize the fact that disabled entities fail validation? (but dependent entities failing validation for other reasons might block enabling entities)
2. Specifically create checks for the `disabled` state (not tied to validation itself) based on just unique entity names
3. point 2, but also checking versions because historically, there can be entities in mixed disabled/enabled state
Beitragsleitfaden
Rechercherichtung
The issue names no files or tests. Start by tracing the V3 API entity-enable operation and how dependencies are represented, using the DatasetA example to compare all entity versions and disabled states. Done means re-enabling an entity checks every dependent entity and version and only succeeds when the required dependencies are enabled.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- scala
- Bereich
- api, backend
- Issue-Typ
- Feature
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Aktivitätsstatus
- Veraltet
- Klarheit
- Größtenteils klar
- Anfängerfreundlichkeit
- 35/100