Feature: Ability to define type of every key-value field in an object

[jquesada2016]

Describe the bug

It seems like there's a bug when calculating object paths that prevents one from using arbitrary keys for an object while defining the key's type.

Steps to reproduce

Take the following schema:

DEFINE TABLE test SCHEMAFULL;

DEFINE FILED obj ON test FLEXIBLE TYPE object;
DEFINE FILED obj.* ON test TYPE string;

Doing the following fails, but should work:

CREATE test SET obj = {};

And likewise the following:

CREATE test SET obj = { a: "blah", b: "lah" };

Expected behaviour

I expect to be able to define a schema for an object field that can have arbitrary keys, but still define the sub-field types.

SurrealDB version

SurrealDB command-line interface and server 1.5.0 for linux on x86_64

Contact Details

No response

Is there an existing issue for this?

• I have searched the existing issues

Code of Conduct

• I agree to follow this project's Code of Conduct

[nathanschwarz]

I think this is proper behavior of the parser, since you defined a specific sub property of the flexible object in the schema it should at least contains a test property.
Using CREATE test SET obj = { test: "hello world" }; or CREATE test SET obj = { test: "hello world", a: "don't mind me", b: 10 }; should work.
You could make the test property optional using option<string> for what you want to achieve (thus enforcing a specific type for this specific property), but that is currently failing too (which in this case is a bug).

also not that your schema is incorrect it should be DEFINE FIELD and not DEFINE FILED

[jquesada2016]

I believe whenever there's a * in the path, it should be optional, as it currently is for sub-array types. You can't assume if they key will be present or not.

In the case of * for objects, I don't think it would make sense to restrict objects to require at least 1 key to be present, you can use ASSERT if you need this. It really should be optional, so empty objects should be allowed.

[jquesada2016]

I suppose to emphasize my last point, if you currently write

DEFINE FIELD test.* ON TABLE test TYPE string;

If you run INFO FOR TABLE test, you'll notice that it rewrote the field definition to:

DEFINE FIELD test[*] ...

insinuating that whildcard parts of a type path really should be optional as they are for arrays.

[nathanschwarz]

In my eyes it makes more sense to rely on the subfield definition using the option keyword :

• it's more readable
• it's more practical for the parser implementation (avoiding the need to go back to the parent definition when parsing objects recursively)

Furthermore :

• the ASSERT keyword is supposed to check logical constraints not types constraints (that's why we have SCHEMAFULL definitions)
• the FLEXIBLE keyword is only there to allow extra values not specified in a SCHEMAFULL context, as per the documentation says :

Flexible types allow you to have SCHEMALESS functionality on a SCHEMAFULL table. This is necessary for working with nested object types, which by nature do not have defined fields.

[tobiemh]

Hi @jquesada2016 thanks for opening this issue 😃 👍 ! Currently, in SurrealDB the * path on an object, refers to the object itself, not all of the keys in the object. Therefore when you run the expression RETURN test.*.name it is the same as if you were to write RETURN test.name.

As a result, it's not actually possible to define schema for all fields on an object up front, and without knowing what the keys themselves will be. So for instance, if you were to run DEFINE FIELD obj.* ON TABLE test, this FIELD definition will not actually be applicable to any key on the obj FIELD.

For the moment I'm going to change this issue into a feature request so we can track this behaviour if it is something that we decide to add to SurrealDB 🚀 🎉 ,