Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

V3 API enable should check dependencies #2065

Open
dk1844 opened this issue May 16, 2022 · 0 comments
Open

V3 API enable should check dependencies #2065

dk1844 opened this issue May 16, 2022 · 0 comments
Labels
feature New feature priority: undecided Undecided priority to be assigned after discussion under discussion Requires consideration before a decision is made whether/how to implement

Comments

@dk1844
Copy link
Contributor

dk1844 commented May 16, 2022

Background & Feature

Originating in #2055 (comment), 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 schemaBv3, no mapping CR and definespropertyDefintionB`.

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
@dk1844 dk1844 added feature New feature under discussion Requires consideration before a decision is made whether/how to implement priority: undecided Undecided priority to be assigned after discussion labels May 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature priority: undecided Undecided priority to be assigned after discussion under discussion Requires consideration before a decision is made whether/how to implement
Projects
None yet
Development

No branches or pull requests

1 participant