Conditions for Definitions

[embano1]

Hi,

I am not sure if this is possible at all, but here's my use case: given an input YAML file I want to validate that if property type is set to "A" aConfig must be provided (but not bConfig) and visa versa. Here's an attempt to show what I'm trying to do but note that the definition does not work:

package config

#providerType: "A" | "B"

#provider: {
	type: #providerType
	if #provider.type == "A" {
		aConfig: #aConfig
	}

	if #provider.type == "B" {
		bConfig: #bConfig
	}
}

#aConfig: {
	aAddress: *"https://vc.local/sdk" | string
}

#bConfig: {
	bAddress: *"https://vc.local/sdk" | string
}

And given this yaml it should fail validation:

cfg:
  type: "B"
  aConfig: 
    aAddress: "https://"

Is this possible at all?

[mpvl]

You would typically write something like:

package config

#providerType: "A" | "B"

#provider: type: #providerType

#provider: {
	type: "A"
	aConfig: #aConfig
} | {
	type: "B"   
	bConfig: #bConfig
}

#aConfig: {
	aAddress: *"https://vc.local/sdk" | string
}

#bConfig: {
	bAddress: *"https://vc.local/sdk" | string
}

[embano1]

#provider: {
	type: "A"
	aConfig: #aConfig
} | {
	type: "B"   
	bConfig: #bConfig
}

If I have multiple type "switches" in this scenario (think K8s VolumeSource type as a valid example), this could get messy, right?

[mpvl]

As long as all types are known and the user is required to specify a type (I believe this is the case for VolumeSource, IIRC), this works fine. There are some performance issues with this approach, but they are fixable.

In the case where a constraint is only added for known types, things get a bit tricky. You would then have to resort to the if statement as you did. With the query proposal this gets a bit neater again. One could then have a list with all known types and do

#provider: {
    T=type: string

    for x in #KnownTypes.[_:{type: T}] { x }  // mix in constraints for known types
}
#KnownTypes: [
    { type: "A", ...},
    { type: "B", ...},
]

But this is not yet implemented.

[mpvl]

Note, btw, that you can also write #provider: #TypeA | #TypeB | ... | #TypeN and define the types elsewhere.

[mpvl]

$ openapi: unsupported top-level field "cfg":
./config.cue:23:1

Interesting point. If you think it will be useful to simply ignore such top-level regular fields, or to allow the --force or -i flag to override this behavior, feel free to file a feature request.

[embano1]

Thank you Marcel, I'll file an issue for this.

Just curious: why does cue vet not complain if I omit the cfg directive or have it in the schema as #cfg: ... definition instead of struct type?

cue vet validation with the above yaml example would only fail if I have a cfg: struct defined (which then leads to the openapi issue).

I thought having a schema (with definitions only) would suffice when using it in cue vet against a yaml file to validate?

May be I'm missing something here.

[cueckoo]

This discussion has been migrated to cue-lang/cue#961.

For more details about CUE's migration to a new home, please see cue-lang/cue#1078.