You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2022/12/20 18:01:13 UTC
LATERAL
On 20/12/2022 17:24, Marco Neumann wrote:
> OK I will repeat this elsewhere again but as you are aware there was
> a good discussion on the SPARQL-12 list with plenty of suggestions.
> maybe something like Sideways Information Passing
> or correlate subquery join.
Noting I didn't choose the name.
The keyword is "LATERAL" not "LATERAL JOIN".
(SIP is an implementation technique for joins - it is best if the
ordering of the left-right flow is "jump forwards")
SQL has some several forms of correlated subquery.
I see a suggestions - it's more like exploring the space - no consensus.
LATERAL is the one that examples come back to.
The nearest seems to be FOR EACH but that isn't infix syntax which
causes more text.
"flatMap" is not data-user friendly.
----
Without nested results tables, it won't solve the general GraphQL case.
As per discussion.
And nested results tables would be a whole different design.
----
If variables must be named:
1: It is more work for the user in the common case.
2: Putting a projection in the subquery for the uncommon cases seems
better UX
3: What happens if a variable is not bound?
4: Not the same as EXISTS so no implementation sharing.
Andy
PS Historical note:
LATERAL is the semantics for SPARQL 1.0 LC1
Re: LATERAL
Posted by Marco Neumann <ma...@gmail.com>.
I take note of your keyword suggestion "LATERAL" vs "LATERAL JOIN".
On Tue, Dec 20, 2022 at 6:01 PM Andy Seaborne <an...@apache.org> wrote:
> On 20/12/2022 17:24, Marco Neumann wrote:
> > OK I will repeat this elsewhere again but as you are aware there was
> > a good discussion on the SPARQL-12 list with plenty of suggestions.
> > maybe something like Sideways Information Passing
> > or correlate subquery join.
>
> Noting I didn't choose the name.
>
> The keyword is "LATERAL" not "LATERAL JOIN".
>
> (SIP is an implementation technique for joins - it is best if the
> ordering of the left-right flow is "jump forwards")
>
> SQL has some several forms of correlated subquery.
>
> I see a suggestions - it's more like exploring the space - no consensus.
> LATERAL is the one that examples come back to.
>
> The nearest seems to be FOR EACH but that isn't infix syntax which
> causes more text.
>
> "flatMap" is not data-user friendly.
>
> ----
>
> Without nested results tables, it won't solve the general GraphQL case.
> As per discussion.
>
> And nested results tables would be a whole different design.
>
> ----
>
> If variables must be named:
>
> 1: It is more work for the user in the common case.
>
> 2: Putting a projection in the subquery for the uncommon cases seems
> better UX
>
> 3: What happens if a variable is not bound?
>
> 4: Not the same as EXISTS so no implementation sharing.
>
> Andy
>
> PS Historical note:
> LATERAL is the semantics for SPARQL 1.0 LC1
>
>
--
---
Marco Neumann