-
Notifications
You must be signed in to change notification settings - Fork 21
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
Feature/jld select iri resolution #214
Conversation
There are some js tests that aren't passing, but I want to make the test suite more comprehensive so that we're testing the same thing across platforms and builds. One at a time.
…ion in results Variables being passed from where statement to where statement always contained only values. For .-o object values, certain downstream processes also need the datatype (e.g. if an IRI, we need to resolve the IRI's value if value is in 'select' statement). Now 'o' values passed through are always two-tuples: [value datatype]. This mean intermediate steps need to know if the value coming through is a two-tuple, so in the query parsing we retain the knowledge of which var is a two-tuple and perform appropriate deconstruction. Also, because mixed-types are allowed, it could be that a object value in one where statement (e.g. ex:friend) might be passed to the subject of the next statement - but if the object value is not an IRI then it will break the following where statement. We now filter for only IRI values in the scenario. Grouping is also an area that requires some additional consideration of the values now being passed in, and that is also adjusted.
…pes] - consolidate
If possible let's retarget this at the main branch once I finish merging the existing feature/jld into it. Should hopefully not be too long. I'll post an update in here when it's done. |
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.
🔢
In case my earlier comment didn’t make it clear, please don’t merge this into either branch just yet. Thank you! |
Re-targeted at |
# Conflicts: # src/fluree/db/query/analytical_parse.cljc # src/fluree/db/query/fql.cljc # test/fluree/db/query/json_ld_compound_test.clj # test/nodejs/flureenjs.test.js
This is a significant change to compound queries in that it now passes both .-o values and datatypes as two-tuples.
Datatype is needed for some downstream operations (e.g. changing a subject integer ID into an IRI in
select
output). Other operations also need to verify they are working with same-type data, since mixed types can be present for any predicate - e.g. a 'max' function can only operate on numbers, or an object that is an IRI, like :ex/friend's value, can only be passed into the subject of the subsequent where statement if the value is actually an IRI.. so if any other datatypes exist for that value it must be filtered out.Now that some two-tuple values are being passed through where, grouping, and select statements - it must be tracked so the operations receiving the values know if it is getting a two-tuples. This could be done by checking every incoming value to see if it is a two-tuple but that would be very inefficient if we can know this up-front.
As a result of this change, an example of how output changes is this query:
Now correctly outputs:
whereas prior to this PR, the output would have integer ids for all ?s and ?p values, and the ?o values that are IRIs (the last two in the above results) would also be the integer ID.