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 (JIRA)" <ji...@apache.org> on 2015/06/17 11:31:01 UTC
[jira] [Comment Edited] (JENA-963) OpAsQuery does not process
HAVING (COUNT(?value) > 1) correctly.
[ https://issues.apache.org/jira/browse/JENA-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589519#comment-14589519 ]
Andy Seaborne edited comment on JENA-963 at 6/17/15 9:30 AM:
-------------------------------------------------------------
These are the different cases:
_Case 1_
{noformat}
SELECT ?s { ?s ?p ?o } GROUP BY ?s
{noformat}
select => project-group
_Case 2_
{noformat}
SELECT (count(?p) as ?cp) { ?s ?p ?o } GROUP BY ?s
{noformat}
select/aggregate => project-extend-group
_Case 3_
{noformat}
SELECT ?s { ?s ?p ?o } GROUP BY ?s HAVING (count(*) > 1 )
{noformat}
select/having+aggregate => project-filter-group
_Case 4_
{noformat}
SELECT ?s { ?s ?p ?o } GROUP BY ?s HAVING (?s > 1 )
{noformat}
select/having-expression => project-filter-group
_Case 5_
{noformat}
SELECT (count(?p) as ?cp) { ?s ?p ?o } GROUP BY ?s HAVING (?cp > 1 )
{noformat}
select/aggregate/having => project-filter-extend-group
An approach is to classifiy at the point {{(project)}} is seen. Programmatically match
{noformat}
(project (filter? (extend? (group)
{noformat}, then process the matched parts specifically to form the grouping, extracting theparts that go into the {{Query}} object. Process a non-match with the visit style without needing to cope with the possibility of being in a group.
Related: make clear that the OpAsQuery.Converter works on one query level.
Overall, the form of a query algebra expression is:
{panel:title=SPARQL syntax processing}
Limit/Offset
Distinct/reduce
project
OrderBy
Bindings
having
select expressions
group
{panel}
leading to
{noformat}
slice-distinct/reduce-project-filter-extend-extend-group-pattern
{noformat}
There are 2 cases of extend, one for expressions in SELECT and one for renaming aggregates. Aggregates go though a temporary variable in case they are used multiple times.
{noformat}
SELECT DISTINCT (Count(*) AS ?C1) (str(?s) AS ?str) {
?s ?p ?o
}
GROUP BY ?s
HAVING (Count(*) > 1)
{noformat}
{noformat}
(distinct
(project (?C1 ?str)
(filter (> ?.0 1)
(extend ((?str (str ?s)))
(extend ((?C1 ?.0))
(group (?s) ((?.0 (count)))
(bgp (triple ?s ?p ?o))))))))
{noformat}
was (Author: andy.seaborne):
These are the different cases:
_Case 1_
{noformat}
SELECT ?s { ?s ?p ?o } GROUP BY ?s
{noformat}
select => project-group
_Case 2_
{noformat}
SELECT (count(?p) as ?cp) { ?s ?p ?o } GROUP BY ?s
{noformat}
select/aggregate => project-extend-group
_Case 3_
{noformat}
SELECT ?s { ?s ?p ?o } GROUP BY ?s HAVING (count(*) > 1 )
{noformat}
select/having+aggregate => project-filter-group
_Case 4_
{noformat}
SELECT ?s { ?s ?p ?o } GROUP BY ?s HAVING (?s > 1 )
{noformat}
select/having-expression => project-filter-group
_Case 5_
{noformat}
SELECT (count(?p) as ?cp) { ?s ?p ?o } GROUP BY ?s HAVING (?cp > 1 )
{noformat}
select/aggregate/having => project-filter-extend-group
An approach is to classifiy at the point {{(project)}} is seen. Programmtically match {{project filter? extend? group}}, then process a group specially to extract the parts that go into the {{Query}} object.
Related: make clear that the OpAsQuery.Converter works on one query level.
> OpAsQuery does not process HAVING (COUNT(?value) > 1) correctly.
> ----------------------------------------------------------------
>
> Key: JENA-963
> URL: https://issues.apache.org/jira/browse/JENA-963
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
> Affects Versions: Jena 3.0.0
> Reporter: Andy Seaborne
> Attachments: Jena963_OpAsQuery.java, ReportOpAsQuery.java
>
>
> Reported: http://mail-archives.apache.org/mod_mbox/jena-users/201506.mbox/%3CCA%2BEd63nzgDA_bShyhQvukED%2BPTiPxSAggo2VmD30J8ZwHr6vUA%40mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)