# LIMIT not respected in Javascript-submitted query

**URL:** <https://community.stardog.com/t/limit-not-respected-in-javascript-submitted-query/1282>\
**Category:** Bug\
**Created:** [September 10, 2018, 3:35pm UTC](https://community.stardog.com/t/limit-not-respected-in-javascript-submitted-query/1282 "2018-09-10T15:35:50Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![arwesterinen](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/arwesterinen/32/40_2.png) [@arwesterinen](https://community.stardog.com/u/arwesterinen)\
**Post date:** [September 10, 2018, 3:35pm UTC](https://community.stardog.com/t/limit-not-respected-in-javascript-submitted-query/1282/1 "2018-09-10T15:35:50Z")

</div>

The query …

```auto
PREFIX cco: <http://www.ontologyrepository.com/CommonCoreOntologies/> 
PREFIX event: <http://ontology.com/Event#> 
PREFIX general: <http://ontology.com/GeneralConcepts#> 
SELECT ?region (COUNT(distinct ?event) as ?countOfMurders) 
FROM <http://graph.com> 
FROM NAMED <http://ontology.com> 
WHERE { 
      { graph <http://ontology.com> {
        ?type rdfs:subClassOf* event:MurderOrHomicide . 
         ?country a cco:Country ; rdfs:label ?coLabel .
          BIND (str(?coLabel) as ?checkLabel) . 
         } }
    ?event a ?type ; general:located_at ?loc . 
    ?loc rdfs:label ?region .
    FILTER (?checkLabel = ?region) .
} GROUP BY ?region 
ORDER BY DESC(?countOfMurders)
LIMIT 15

```

Returns all regions and their counts. The LIMIT is not respected.

Here is the query plan …

```auto
prefix cco: <http://www.ontologyrepository.com/CommonCoreOntologies/>
prefix event: <http://ontology.com/Event#>
prefix general: <http://ontology.com/GeneralConcepts#>

From <http://graph.com>
From Named <http://ontology.com>
Slice(offset=0, limit=15) [#15]
`─ Projection(?region, ?countOfMurders) [#119]
   `─ OrderBy(DESC(?countOfMurders), offset=0, limit=15) [#119]
      `─ Group(by=[?region] aggregates=[(COUNT(DISTINCT ?event) AS ?countOfMurders)]) [#119]
         `─ Filter(?checkLabel = ?region) [#119]
            `─ MergeJoin(?loc) [#238]
               +─ Sort(?loc) [#238]
               │ `─ MergeJoin(?event) [#238]
               │ +─ Sort(?event) [#5.4K]
               │ │ `─ MergeJoin(?type) [#5.4K]
               │ │ +─ Sort(?type) [#1.4K]
               │ │ │ `─ Bind(Str(?coLabel) AS ?checkLabel) [#1.4K]
               │ │ │ `─ LoopJoin(_) [#1.4K]
               │ │ │ +─ MergeJoin(?country) [#238]
               │ │ │ │ +─ Scan[POS](?country, <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>, cco:Country){<http://ontology.com>} [#238]
               │ │ │ │ `─ Scan[PSO](?country, <http://www.w3.org/2000/01/rdf-schema#label>, ?coLabel){<http://ontology.com>} [#2.4K]
               │ │ │ `─ PropertyPath(event:MurderOrHomicide -> ?type in <http://ontology.com>, minLength=0) [#6]
               │ │ │ `─ Scan[POS](?type, <http://www.w3.org/2000/01/rdf-schema#subClassOf>, event:MurderOrHomicide){<http://ontology.com>} [#3]
               │ │ `─ Scan[POS](?event, <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>, ?type) [#11.2M]
               │ `─ Scan[PSO](?event, general:located_at, ?loc) [#423K]
               `─ Scan[PSO](?loc, <http://www.w3.org/2000/01/rdf-schema#label>, ?region) [#5.4M]

```

Although the query plan indicates “slice”, no slicing is performed.

I know that the query can be written differently/more efficiently, but this structure is required due to its being run against multiple triple stores (and other bugs are present in those stores). The problem is checking the location value (which is just a string) against the country label (which is a string with a language tag).

Andrea

---

<div class="post-metadata">

**Author:** ![arwesterinen](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/arwesterinen/32/40_2.png) [@arwesterinen](https://community.stardog.com/u/arwesterinen)\
**Post date:** [September 10, 2018, 3:58pm UTC](https://community.stardog.com/t/limit-not-respected-in-javascript-submitted-query/1282/2 "2018-09-10T15:58:52Z")

</div>

To be clear, this is only in the Javascript interface. The query works correctly through the command line.

Perhaps I must translate the LIMIT into the JS limit: xxx parameter?

Andrea

---

<div class="post-metadata">

**Author:** ![stephen](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/stephen/32/27_2.png) [@stephen](https://community.stardog.com/u/stephen)\
**Post date:** [September 12, 2018, 11:35am UTC](https://community.stardog.com/t/limit-not-respected-in-javascript-submitted-query/1282/3 "2018-09-12T11:35:18Z")

</div>

Andrea,

When you say the “Javascript interface,” do you mean using stardog.js directly to execute a query, or the web console interface at localhost:5820? If it’s the latter, it may be that the web console is transforming the query before sending it and changing or removing the limit. If you enable slow query logging (with a low threshold like 0s) you should be able to see in the log what query is actually being sent.

---

<div class="post-metadata">

**Author:** ![arwesterinen](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/arwesterinen/32/40_2.png) [@arwesterinen](https://community.stardog.com/u/arwesterinen)\
**Post date:** [September 12, 2018, 3:31pm UTC](https://community.stardog.com/t/limit-not-respected-in-javascript-submitted-query/1282/4 "2018-09-12T15:31:19Z")

</div>

When I run stardogjs.query.execute and have a ‘LIMIT 15’ in my query, it is not respected. The LIMIT passed as a parameter overrides the LIMIT in the query.

I would have expected the LIMIT in the query to take precedence.

Andrea

---

<div class="post-metadata">

**Author:** ![stephen](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/stephen/32/27_2.png) [@stephen](https://community.stardog.com/u/stephen)\
**Post date:** [September 14, 2018, 1:44pm UTC](https://community.stardog.com/t/limit-not-respected-in-javascript-submitted-query/1282/5 "2018-09-14T13:44:02Z")

</div>

Which of the two limits would or should take precedence seems to be quite subjective (even internally we have a little bit of a split). If you only specify the limit in the query, does that work as intended?