LIMIT in SPARQL queries on virtual graphs

[PaulZH]

Stardog 4.1.1

virtual graph on Microsoft SQL server

Query:

./stardog query CRAB "SELECT * {GRAPH <virtual://crab> {<http://id.vlaanderen.be/id/adres/84401> ?p ?v.}}"

Works

Query:

./stardog query CRAB "SELECT * {GRAPH <virtual://crab> {<http://id.vlaanderen.be/id/adres/84401> ?p ?v.}} LIMIT 15"

Error

com.complexible.stardog.plan.eval.operator.OperatorException: Error executing SQL query: 

Incorrect syntax near 'OFFSET'.

...
WHERE
(QVIEW1."AdresID" = '84401') AND
(QVIEW1."StraatID" = QVIEW2."StraatID") AND
(QVIEW2."GemeenteID" = QVIEW3."GemeenteID") AND
(QVIEW3."TaalISOCode" = 'NLD') AND
(QVIEW1."StraatID" = QVIEW4."StraatID") AND
(QVIEW4."TaalISOCode" = 'NLD') AND
QVIEW4."Naam" IS NOT NULL
) SUB_QVIEW
OFFSET 0 ROWS
FETCH NEXT 15 ROWS ONLY

[Evren Sirin]

I believe in SQL Server LIMIT is not allowed without an ORDER BY
clause so if you add that this should work. We'll make changes to
perform the limit on the Stardog side in these cases but performance
might not be great for queries with large results.

Best,
Evren

> --
> -- --
> You received this message because you are subscribed to the C&P "Stardog"
> group.
> To post to this group, send email to sta...@clarkparsia.com
> To unsubscribe from this group, send email to
> stardog+u...@clarkparsia.com
> For more options, visit this group at
> http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en

[PaulZH]

Hi Evren,

This worked in the previous version with LIMIT only.

./stardog query KBO "SELECT * {GRAPH <virtual://exploitant> {?x a <http://www.w3.org/ns/locn#Address>}} LIMIT 5"
+------------------------------------------------------------------------+
|                                   x                                    |
+------------------------------------------------------------------------+
| http://id.milieuinfo.be/cbb/adres/1700/Sint-Alenalaan/89#id            |
| http://id.milieuinfo.be/cbb/adres/1750/Hendrik%20Ghijselenstraat/11#id |
| http://id.milieuinfo.be/cbb/adres/1750/Kamstraat/52#id                 |
| http://id.milieuinfo.be/cbb/adres/1780/de%20Limburg%20Stirumlaan/58#id |
| http://id.milieuinfo.be/cbb/adres/1785/Middelstraat/45#id              |
+------------------------------------------------------------------------+

Query returned 5 results in 00:00:41.455

[Evren Sirin]

Yes, it worked in the previous version where solution modifiers
(OFFSET, LIMIT, ORDER BY) were not being pushed into SQL causing the
performance problems you reported on June 6. Now solution modifiers
are being pushed into SQL which solves the performance problem. But
SQL Server seems to have special restrictions on when LIMIT can be
used causing this new issue. This is why you need the workaround for
SQL Server. We'll make pushing solution modifiers into SQL conditional
based on the backend capabilities but then you'll again have poor
performance with SQL Server so adding ORDER BY to your queries might
be a better option.

Best,
Evren

[PaulZH]

OK, clear now. Many thanks for the clarification.

Paul