Bug: Can't define a schema with flexible object keys about surrealdb HOT 4 OPEN

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

from surrealdb.

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.

from surrealdb.

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.

from surrealdb.

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.

from surrealdb.