Closed dpetran closed 3 months ago
Should we move :values into the where clause? I'd imagine it is there because there could be multiple where clauses, or sub-queries which might have its own set of values.
It's not a bad idea, and it clearly works for SPARQL. I don't think it would be too complex to support, just a new (defmethod match-pattern :values)
that directly injects into the solution-ch, but there may be some finicky bits about pattern ordering. And it would save me from having to rearrange the translated query : )
Rebased on https://github.com/fluree/db/pull/777
We got around it by translating it into a :bind pattern. However, a :bind pattern can only bind a single value to a variable, so we limited the scope of a VALUES pattern to only a single value.
:bind
patterns can take any number of mappings of values to variables.
We got around it by translating it into a :bind pattern. However, a :bind pattern can only bind a single value to a variable, so we limited the scope of a VALUES pattern to only a single value.
:bind
patterns can take any number of mappings of values to variables.
Right, maybe it is better stated that a :bind pattern can only bind a single value per variable, whereas :values can bind multiple values per variable.
Rebased on https://github.com/fluree/db/pull/777
In SPARQL, a VALUES pattern can appear inside a WHERE clause alongside other patterns. In FQL :values is its own clause. This mismatch makes translating directly awkward, since we need to insert our translated pattern at a different point in the parse tree than where we are at translation time.
We got around it by translating it into a :bind pattern. However, a :bind pattern can only bind a single value to a variable, so we limited the scope of a VALUES pattern to only a single value.
This gets around it by "tagging" the translated value pattern and then after the whole parsing is done, moving it to the correct place in the tree: see
format-values
. It's awkward, but it gives much more flexibility to the user.