Get signature as array for enumerated values co-located to fields?

[Mike]

Let’s say we have the following definition with the enumerated field list:

{
  "name": "Test",
  "coll": "Collection",
  "ts": "2024-08-20T09:22:00.373Z",
  "fields": {
    "list": {
      "signature": "\"No1\" | \"No2\" | \"No3\""
    }
  }
}

2 things:

First:

The signature is an escaped string rather then an array, so I need to slice the string to get the single entries instead of simply calling an array loop. It would make sense to me, if the signature would be stored already in an iteratable way:

{
  "name": "Test",
  "coll": "Collection",
  "ts": "2024-08-20T09:22:00.373Z",
  "fields": {
    "list": {
      "signature": ["No1", "No2", "No3"]
    }
  }
}

Second:

Is it somehow possible to get value and type co-located in one request?

{
  "@doc": {
    "id": "406728886462709968",
    "coll": {
      value": "Test",
      "type": "Collection"
    },
    "ts": {
      "value": "2024-08-20T09:22:22.770Z",
      "type": "Time"
    },
    "list": {
      "value": "No1",
      "type": ["No1", "No2", "No3"]
    }
  }
}

Use Case: I would like to show the options of list in the Frontend as selectable fields.

[ptpaterson]

Hi @Mike!

Field definitions in FQL

There is a .split() method on strings. Does that help? string.split() - Fauna Docs

The signature is a valid FSL type definition. We document FSL for customers to use and Fauna knows how to parse it. Parsing FSL remains an implementation detail which can (and does) evolve as features are added and updated. Changing the signature property to a walkable AST structure would mean we’d have to stabilize and document an additional API. Whereas, field definitions using FSL can safely be stabilized shortly with GA of schema enforcement and migrations.

Here is a very contrived example, but the point is that types can be arbitrary, and complex. Handling any type AST would very likely not be “simply calling an array loop”.

Decorating a document with types

@Mike

Is it somehow possible to get value and type co-located in one request?

When you create your own objects, they are no longer Document types, so no, you cannot construct the proposed object and also be tagged as @doc. But I see no reason why you could not otherwise create such an object.

Here’s an example, though I’m not trying here to detect and process any union or intersection types.

let SchemaDecorator = doc => {
  let coll_def = doc.coll.definition

  let entries = Object.entries(doc)

  let decorated_entries = entries.map(e => {
    let key = e[0]
    let value = e[1]

    let new_value = if (key == "id") {
      value
    } else if (key == "ts") {
      { value: value, type: "Time" }
    } else if (key == "coll") {
      { value: coll_def.name, type: "Collection" }
    } else if (coll_def.fields != null) {
      { value: value, type: coll_def.fields[key]?.signature }
    } else {
      { value: value, type: null }
    }

    [key, new_value]
  })

  Object.fromEntries(decorated_entries)
}

You could also probably make this a recursive UDF to handle decorating nested types like objects and arrays.