Bug: Can't define a schema with flexible object keys

[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.