Validating a stringy UUID

[hansbogert]

I'd like to validate strings which hold UUIDs, so e.g.,

import "uuid"

[string]: uuid.Valid

augmentedUuid: "0f72ceb0-b566-4f3e-9bd1-e197c751ad1e.xxx"

Of course the "....xxx" makes this non-valid. However, I know that all my values will have ".xxx" suffixed, how would I incorporate this fact and still make a sound UUID validation.

Introducing a hidden helper value with some strings.Split magic would work for this (maybe too much) dumbed down example.

My actual problem involves the follow structure:

import (
        "uuid"
        "strings"
)

// data, which in the original problem is actually json
records: {
 "record-will-have-uuid-x": {
    name: "0f72ceb0-b566-4f3e-9bd1-e197c751ad1e.xxx"
  }
 "record-will-have-uuid": {
    name: "0f72ceb0-b566-4f3e-9bd1-1234566666ee.xxx"
  }
 "record-will-not-have-uuid": {
    name: "no-uuid.xxx"
  }
}

records: [string]: _record

_record: {
  name: string
  ...
}

// the check cue here:
records: [=~".*will-have-uuid.*"]: _record & {
  _uuid: strings.Split(name, ".")
  _uuid: uuid.valid
}

however the following when evaluating:

records.[]._uuid: reference "name" not found:
    ./minimal.cue:28:24

[infogulch]

You probably want an alias: https://cuelang.org/docs/reference/spec/#aliases

In your case I think it would look like this:

records: RecordName=[=~".*will-have-uuid.*"]: _record & {
  _uuid: strings.Split(RecordName, ".")
  _uuid: uuid.valid
}

Edit: Or maybe [RecordName=~".*will-have-uuid.*"].

[hansbogert]

I stand corrected, the whole record is now aliased, not just the string key , so the more complete solution would be:

records: Record=[=~".*will-have-uuid.*"]: _record & {
  _uuid: strings.Split(Record.name, ".")[0]
  _uuid: uuid.valid
}

[infogulch]

I'm glad it's working for you!

I think in this case we can actually skip the alias and get the name with unification:

records: [=~".*will-have-uuid.*"]: _record & {
  name: string
  _uuid: strings.Split(name, ".")[0] & uuid.valid
}

[hansbogert]

@infogulch that works and is probably better, but it feels as if i have to redefine name, it should already be defined as we're unifying with _record which already holds a name right?

[infogulch]

I think it has more to do with it not being present in the local lexical scope, so the name needs to be bound again.

Consider what could happen if names from unified structs were put in scope automatically: if you add a field to a struct it could shadow a name somewhere else, changing the meaning of distant parts of the code. I suspect this is unavoidable.

I guess you could bind the name without specifying the type again like: name: _

[hansbogert]

but they kinda are already in scope right? If a struct which is unified alters its fields it can already have consequences in distant parts.
But maybe I should just get a better feeling of Cue, this is with <10 hours of intensively writing Cue. I'm very grateful for the elegant solution provided!