History | Log In     View a printable version of the current page. Get help!  
Issue Details [XML]

Key: SES-822
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Jeen Broekstra
Reporter: Barry Norton
Votes: 0
Watchers: 1

If you were logged in you would be able to see more operations.

ORDER by GROUP aggregate

Created: 24/Aug/11 12:33 PM   Updated: 25/Aug/11 06:16 AM
Component/s: None
Affects Version/s: 2.5.0
Fix Version/s: 2.5.1

Given this data:

@prefix ex : <http://www.ontotext.com/people#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
ex:barry1 foaf:knows ex:barry2 , ex:naso.
ex:barry2 foaf:knows ex:barry1 , ex:naso.

The following query:

PREFIX foaf:<http://xmlns.com/foaf/0.1/>
SELECT ?popular
     WHERE {?someone foaf:knows ?popular}
     GROUP BY ?popular
     ORDER BY DESC (COUNT(?someone))

Gives these results with the Sesame memory store:


These results are not expected since :naso is known by two people, the others only one.

If the aggregate is bound in the project then the behaviour is as expected:

PREFIX foaf:<http://xmlns.com/foaf/0.1/>
SELECT ?popular (COUNT(?someone) AS ?popularity)
     WHERE {?someone foaf:knows ?popular}
     GROUP BY ?popular
     ORDER BY DESC (?popularity)

 All   Comments   Change History      Sort Order:
Comment by Ruslan Velkov [24/Aug/11 04:54 PM]
There are 2 issues with Order and aggregates:

1. Aggregate functions are not registered to the GroupIterator if they do not reside in the Projection, so no aggregate is evaluated after receiving the multisets. So in this case we receive only the keys to the multisets, namely :barry2, :naso, :barry1.

2. ORDER BY throws exception when the comparator is set to an expression other than the built-in ones (Var, ValueConstant, BNodeGenerator, Bound, Str, Label, Lang, LangMatches, ..., IsURI, IsLiteral, ..., Like, And, Or, Not, ..., Exists, If). Here is the exception trace:

org.openrdf.query.QueryEvaluationException: Unsupported value expr type: class org.openrdf.query.algebra.Count
at org.openrdf.query.algebra.evaluation.impl.EvaluationStrategyImpl.evaluate(EvaluationStrategyImpl.java:1041)
at org.openrdf.query.algebra.evaluation.util.OrderComparator.evaluate(OrderComparator.java:70)
at org.openrdf.query.algebra.evaluation.util.OrderComparator.compare(OrderComparator.java:44)
at org.openrdf.query.algebra.evaluation.util.OrderComparator.compare(OrderComparator.java:1)

Looking at the Sesame source code, I'm not sure whether this query misbehaviour is due to real issues in Sesame or the query itself is not well formulated.

Comment by Jeen Broekstra [25/Aug/11 04:52 AM]
I have run into a similar issue before, I vaguely remember. will check out.

Comment by Jeen Broekstra [25/Aug/11 06:16 AM]
Problem found, had to do with ORDER by processing in the TupleExprBuilder. I've managed to fix the issue, added two testcases for it in the manifest set (aggregates/sparql11-order-02 and aggregates/sparql11-order-03), both greenline now.