Anticipate snapshot changes

[ewuerger]

This PR anticipates the structural changes to the snapshot interface. There are no long_names anymore in the data_types section. Instead only id's are used.

[Wuestengecko]

I think at this point it might make sense to actually rename the data_types key to enumerations or something, because that's really all that is here. data_types suggests that there might be more to it, like "subtype of integer"-style things such as a "UserID".

And similarly below: Currently the type_id key is used to reference the definitions in data_types; that could be renamed to, say, enum_def (or long form enumeration_definition, or simply just enumeration?).

[Wuestengecko]

This looks odd, are identifier and long_name supposed to be the same now? I thought identifier was the internal unique ID and long_name the user-facing descriptive text.

[Wuestengecko]

Typo.

Suggested change

	"description": "The EnumerationDataTypeDefinition identifier for assication of the available options.",
	"description": "The EnumerationDataTypeDefinition identifier for association of the available options.",

[Wuestengecko]

If I'm not mistaken, this schema would ask for:

data_types:
  something:
    - some_key: a string
      other_key: another string
    - third_key: more string

What we actually have in the tests is:

data_types:
  something:
    - a string
    - another string

Which would mean, in terms of a schema:

Suggested change

	"items": {
	"patternProperties": {
	".": {
	"type": "string"
	}
	}
	}
	"items": {
	"type": "string"
	}

[Wuestengecko]

We can avoid this type: ignore (and the second one further down on line 1258) by changing the definitions of act.AttributeDefinition and act.EnumAttributeDefinition like this:

class AttributeDefinition(te.TypedDict):
    long_name: str
    type: t.Literal["Boolean", "Date", "Float", "Integer", "String"]

class EnumAttributeDefinition(te.TypedDict, total=False):
    long_name: te.Required[str]
    type: te.Required[t.Literal["Enum"]]
    values: list[str]
    multi_values: bool
    type_id: str

This enables the same either-or logic that the JSON schema also uses, and allows mypy to discriminate between the two cases with the above check of if data["type"] == "Enum".

---

the same either-or logic that the JSON schema also uses

Taking this thought a step further, there actually appears to be a project out there which aims to generate Python types from a JSON schema. This might be worth a look at, so that we don't have to maintain the same information in two places and formats manually.

https://github.com/sbrunner/jsonschema-gentypes

It can also be configured as pre-commit hook, however I haven't yet looked at it in detail - it might as well turn out to not be suited (or too limited) for our use case.