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

TypeDB 3.0: enumerated value restrictions #7023

Open
flyingsilverfin opened this issue Apr 3, 2024 · 1 comment
Open

TypeDB 3.0: enumerated value restrictions #7023

flyingsilverfin opened this issue Apr 3, 2024 · 1 comment
Milestone

Comments

@flyingsilverfin
Copy link
Member

Problem to Solve

TypeQL doesn't have a way to represent enums, or even values restricted to a set of values for an attribute, a very common use case (example: a form's title may be Mr|Ms...).

Current Workaround

Users try to use a regex: @regex("Mr|Ms"), which works but is non-canonical and not particularly performant to insert.

Proposed Solution

We will introduce a value restriction such as @values(...) which takes a list of values. This allows restricting values to a set of values. (note: syntax not finalised?)

define
  title sub attribute, value string @values("Mr", "Ms"...);

This also allows using specific longs or dates very naturally:

define
  teenage-years sub attribute, value long @values(11,12,13,14,15...);

Although the use case for these may be somewhat unusual.

@brettforbes
Copy link

brettforbes commented Apr 28, 2024

This is brilliant, but can we slightly expand the use case please?

Controlled dictionaries using Vocabularies and Enums are very common in many fields, including cybersecurity, and super valuable. The key difference between a vocab or an enum is whether one can add more values or not, viz:

  • Vocabularies are a list of words, that can be added to. For example
  • Enums are a list of words, that cannot be added to. For example

Controlled vocabularies are most often displayed in User Interfaces in drop down list boxes (Enum), or combo list boxes (Vocab) that enables extra values to be added.

The key differences between your current proposition and more formal Controlled Vocabulary Types is:

  1. It is not a list of string, instead it is a key-value dictionary
  2. The key is the term being used; the value is its formal definition. Mostly only the key is required in a certain field, but sometimes people want to refer to the definition (e.g. mouseover tooltip description).
  3. The dictionary has a formal name, that acts as its binding property, account-type-ov or windows-registry-datatype-enum in the above examples. One would query using this name.

This goes beyond the simple enum, but perhaps this functionality could be put together by combining an enum and a struct.

Assuming this can be done, then the critical issue is that we need a second type of Enum, one that can be added to dynamically

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants