Conversation
| When get answers of typeql read query | ||
| """ | ||
| match | ||
| let $metadata = function_get_doc("get_random_number"); |
| Then connection open read transaction for database: typedb | ||
| When get answers of typeql read query | ||
| """ | ||
| match let $metadata = get_constraint_metadata("key", "person", "<constraint>", "<rhs>"); |
There was a problem hiding this comment.
I think this should be get_xxx_meta to match the annotation
| Then connection open read transaction for database: typedb | ||
| When get answers of typeql read query | ||
| """ | ||
| match let $metadata = get_metadata("key", "person"); |
There was a problem hiding this comment.
Also I think the first arg should be the type, then the key? any specific reason it's this way around?
There was a problem hiding this comment.
It feels like the key is the closest conceptually to the function name. @meta("key", ...) -> get_meta("key", ...). That is, we're retrieving the meta("key" in a way.
| Then connection open read transaction for database: typedb | ||
| When get answers of typeql read query | ||
| """ | ||
| match let $doc = get_doc("person"); |
There was a problem hiding this comment.
I actually think that it's powerful to make this a type, not a string input, and also to allow a type variable to be passed in. Then users can do this:
match
$t sub legal-entity;
fetch {
"label": label($t),
"doc": get_doc($t),
};
| When get answers of typeql read query | ||
| """ | ||
| match | ||
| let $doc = get_function_doc("get_random_number"); |
There was a problem hiding this comment.
maybe get_fun_doc? to match keywords
| Then connection open read transaction for database: typedb | ||
| When get answers of typeql read query | ||
| """ | ||
| match let $doc = get_constraint_doc("person", "<constraint>", "<rhs>"); |
There was a problem hiding this comment.
I thin it'll be much easier for people if we just have more functions:
- get_owns_doc
- get_plays_doc
- get_relates_doc
also shorter, and easier to use IMO:
match let $doc = get_owns_doc(person, name);
2 participants
Usage and product changes
Implementation