Feature/subquery

[bplatz]

Adds new subquery capability. Supports multiple parallel subqueries, or nested subqueries.

A new solution-value interface is for select statements to pass formatted solutions for :select clauses instead of final projections as a normal select clause does.

e.g. in EDN - this has a subquery that calculates the average of all favNums, then in the parent query filters to only include users who have a favNum > than the average:

{:context  {:ex "http://example.org/ns/"}
 :select   '[?iri ?favNums]
 :where    ['{:id         ?iri
              :ex/favNums ?favNums}
            [:filter "(> ?favNums ?avgFavNum)"]
            [:query {:where  '{:ex/favNums ?favN}
                     :select '[(as (avg ?favN) ?avgFavNum)]}]]
 :order-by '[?iri ?favNums]}

Tests/examples in: fluree.db.query.subquery-test

[zonotope]

I feel like this should be in a new subquery specific protocol because the solution-value method doesn't apply in all the cases where ValueSelector should be defined.

[bplatz]

I started this change, but both format-value and solution-value are tied to implicit-grouping?. So either solution-value needs to rely on the other protocol. At that point it seems they should be part of the same protocol.

Do you still want them separated out?

[zonotope]

Yeah, I have had reservations about the addition of implicit-grouping? as a protocol method, and especially as a method on this protocol since it was introduced because whether or not something is grouped implicitly is outside the scope of selecting values.

I think the best thing would be to go back to the way it was before and just add the other aggregate selector types to that function as necessary. That would eliminate problems like this and result in more flexibility.

I think that's probably beyond the scope of this particular pr so I might just make that change along with the changes I suggested here in a separate cleanup branch at some point.

[bplatz]

I don't plan to resolve this here - I don't think it is specific to the subquery functionality and can sit as a separate change. We are also still doing some query work, so opinions on ideal solution might change.

[bplatz]

I think all the issues are addressed here @zonotope. @dpetran would be great to move ahead with SPARQL subquery support to go with this.

[zonotope]

🌞