Restrict LIST values for vertex propery (Enum)

[malakeel]

When creating a property on a vertex, I would like to restrict some values to use. For example:

CREATE PROPERTY shirt.size if not exists string LIST ("small", "medium", "large") ;

Basically, I am looking for a built-in way to specify enumerations. Is this possible ?

[lvca]

+1. This is not possible with ArcadeDB at the schema level. It would be a new feature useful to validate the model.

What could be the syntax for that? What about:

CREATE PROPERTY shirt.size if not exists string ENUM ["small", "medium", "large"];

[malakeel]

Sure, if that works.

[gramian]

I like this, but I would express it as a constraint maybe like:

CREATE PROPERTY shirt.size if not exists string (enum ["small", "medium", "large"]);

and what about case sensitivity?

[malakeel]

@gramian
And what if you wanted to add more elements later to the enumeration ?

[gramian]

@malakeel As constraints are not accessible (AFAIK) you couldn't. One would have to use ALTER PROPERTY and reassign all elements plus the new ones.

[gramian]

Dear @malakeel
I don't think there is a dedicated way to do enumerations. However you can use a regular expression constraint on a STRING property, see CREATE PROPERTY under regexp.

[gramian]

Hm, I see. Given your example my first idea is to use an embedded LINK instead of a STRING as property type of shirt.size, but this maybe thinking too relationally (like a star schema).

@lvca would the ENUM extension you think of allow this flow of information (from another type into the enum)?

[malakeel]

@gramian

Do we have something like Check constraints in ArcadeDB ?
If so, then we might be able to solve this easily. A more generic solution is much better, as it allows to handle more cases.
What I don't like about the ENUM approach is:

• They have to be specified during schema creation, and can not be added later. We know that many applications need to have more dynamic enum approach. Java enum works fine for most coding, but for data, they are a bit limited. When you create a java enum, you need to modify it and recompile to use it. For data enum where we just need to use a value from set of values, this can be limiting. Let's take for example the shirt.size, where you can start with (small, medium, large), but then the enum may grow to (x-small, x-large, xx-large ... ) and so on.

• With Enum key word approach, we may not have a way to query available enumerations. Unlike "one-true-look-up table", where you a table for all possible values, and in your check constraints you have to set the value of the column for specific part of that table. So adding additional values to the table is simple. Especially when it comes to design a UI to maintain those types.

If using a LINK is possible, then I would like to find an example as I didn't see any example for using LINK. And I looked at orientdb docs, but didn't get anywhere.

I prefer the relational way here, if possible. Nothing wrong with it when used in the right place.

[gramian]

OK, here is how this can be done:

CREATE PROPERTY shirt.size if not exists LINK

with inserts like:

INSERT INTO shirt SET size = (SELECT FROM size WHERE key == "small")

The downside is that you cannot constrain the link type in the size property AFAIK.

[malakeel]

@gramian

Please refer to Check Constraints

If we have something similar then we can do some thing like

CREATE PROPERTY shirt.size if not exists string (mandatory true, 
                              check (size in ( select key from SIZE))) ;

And even better if we can use a function and provide a constrain id violation. This can be very useful. I know this might be new feature. Let's think about it, so that we handle as many cases as possible without having to add too much functionality.

And definitely we can deprecate the "regex" constraints since it can be done in CHECK constraints, or at least make it take advantage of the new CheckConstraint functionality.

[lvca]

I can see usage for a Postgres-like CHECK, but executing a query for every update/insert could be overkill. I'd prefer to use an ENUM type statically created at the property level, that you can modify with an ALTER PROPERTY. Of course, this list isn't dynamic and can't be very long. If you need to have a dynamic/long set of values, then @gramian solution is preferable. You can create an edge to the SIZE vertex type, be sure to use a unidirectional edge to avoid having a super-node in the SIZE vertex for no reason (like navigating from SIZE to all the connected shirts?).