Skip to content
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

Wrong tuple variable name in FROM clause vs. WHERE clause #11

Closed
fehrenbach opened this issue Nov 4, 2014 · 2 comments
Closed

Wrong tuple variable name in FROM clause vs. WHERE clause #11

fehrenbach opened this issue Nov 4, 2014 · 2 comments

Comments

@fehrenbach
Copy link
Member

Hi,

I have a query that doesn't work:

query { for (r <-- xml)
        where (r.id == 0
           && not(empty(for (ooc <-- xml,
                             oc <-- xml)
                        where (ooc.parent == r.id && oc.parent == ooc.id)
                            [oc])))
          [r]
}

Is this sensible at all?

It produces the following SQL:

select (t1759."id") as "id",(t1759."name") as "name",(t1759."parent") as "parent",(t1759."post") as "post",(t1759."pre") as "pre"
  from xml as t1759
  where ((t1759."id") = (0)) and
     (exists (select 0 as dummy
                from xml as t1768, -- t1760 used but t1768 bound!
                     xml as t1769
               where ((t1760."parent") = (t1759."id")) and ((t1769."parent") = (t1760."id"))))

which doesn't work, because it refers to tuple variable t1760, which is not bound in any FROM clause. Instead, there is a from xml as t1768, but t1768 is never used.

Any suggestions? (I'm not entirely sure the query is valid Links code. If it's not "Your query is wrong!" is a perfectly acceptable answer...)

PS: This is using the current sessions branch at 3477fee.

@fehrenbach fehrenbach changed the title Query compilation Missing table in FROM clause Nov 4, 2014
@fehrenbach
Copy link
Member Author

I have a Links version of the XPath evaluator from the ICFP'13 paper here:
https://github.com/fehrenbach/links-playground/blob/d5adbef68d720b05ee50d3671e1c61ed81cafc86/xpath.links
which fails for all the examples.

James ran the F# version for me, producing this for xp0:

SELECT [t1].[ID]
FROM [dbo].[Data] AS [t0], [dbo].[Data] AS [t1]
WHERE ([t0].[Parent] = @p0) AND ([t0].[Entry] = @p1) AND (EXISTS(
     SELECT NULL AS [EMPTY]
     FROM [dbo].[Data] AS [t2]
     WHERE ([t0].[Entry] = [t2].[Entry]) AND ([t0].[ID] =  
[t2].[Parent]) AND ([t2].[Entry] = [t1].[Entry]) AND ([t2].[ID] =  
[t1].[Parent])
     ))

Whereas my Links version produces this:

select (t1755."id") as "id"
  from xml as t1754,xml as t1755
 where ((t1752."parent") = (-(1))) -- t1752 is not bound, but t1754 is
   and (exists (select 0 as dummy
                  from xml as t1759
                 where ((t1752."id") = (t1759."parent")) and ((t1759."id") = (t1755."parent"))))

where t1749 is not bound and t1751 is not used.

There is some stuff about "Entry"s in the F# version, presumably it uses a slightly different schema.

@fehrenbach fehrenbach changed the title Missing table in FROM clause Wrong tuple variable name in FROM clause vs. WHERE clause Nov 4, 2014
@jamescheney
Copy link
Contributor

Yes, the "entry" field is just an additional value to allow us to store multiple trees one table. This shouldn't matter, from the point of the apparent problem with the Links version, though.

The query in the initial comment looks like it should work to me; in general, any purely conjunctive/SQL-like query ought to work and anything that doesn't ought to yield a type error.

fehrenbach added a commit to fehrenbach/links that referenced this issue Nov 4, 2014
It looked suspicious, so I put the prime, and it seems to work. I really
have no clue. Someone with a clue should have a look whether this makes sense.
slindley added a commit that referenced this issue Nov 5, 2014
@slindley slindley closed this as completed Nov 5, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants