New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
json-api: "table scan"-style query, literal equality and record subsets #2826
json-api: "table scan"-style query, literal equality and record subsets #2826
Conversation
…eral-and-field-equality-query-json-api
…eral-and-field-equality-query-json-api
…oper model by operations
- false cases fail because outer layer still stubbed
…eld-equality-query-json-api
- deals with potential subst introduction as we make VP more abstract
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
…query-json-api' into 2778-literal-and-field-equality-query-json-api
…eld-equality-query-json-api
JSON are also always interpreted with respect to some specified LF types | ||
(e.g. template IDs). As #2777 implies, for example:: | ||
|
||
{"%templates": [{"moduleName": "Foo", "entityName": "A"}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just thinking about this... Maybe %templates
should NOT be an Array
? In this case if typecheck fails, it will be clear what Template
it failed for. I bet we can improve the error reporting and maybe it already provides all required information, but it just looks strange to me that we may return totally unrelated types in one result set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it helps, you can think of the result type as a list of values of variant type, where the variant data constructor is a template ID rather than a string or int. If it does not help, well, we can reconsider elsewhere.
|
||
A JSON object, when considered with a record type, is always interpreted | ||
as a field equality query. Its type context is thus mutually exclusive | ||
with `the forthcoming comparison queries |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add an example here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, because
- this is a statement that no example of x exists, and
- to exemplify indirectly (e.g. by saying "this is always left, and this is always right", though I am skeptical of the value of such an inclusion) would require the full definition of comparison queries as meaningful context, which does not belong in this document until json-api: comparison query #2780.
…eral-and-field-equality-query-json-api
…query-json-api' into 2778-literal-and-field-equality-query-json-api
…eld-equality-query-json-api
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. If not in this PR, please prioritize putting together some documentation for the JSON-API in general, and also for the query syntax.
ledger-service/http-json/src/main/scala/com/digitalasset/http/query/ValuePredicate.scala
Show resolved
Hide resolved
ledger-service/http-json/src/main/scala/com/digitalasset/http/query/ValuePredicate.scala
Outdated
Show resolved
Hide resolved
…query-json-api' into 2778-literal-and-field-equality-query-json-api
Fixes #2778 .
Pull Request Checklist
NOTE: CI is not automatically run on non-members pull-requests for security
reasons. The reviewer will have to comment with
/AzurePipelines run
totrigger the build.