Ticket #72 (assigned defect)

Opened 3 years ago

Last modified 3 years ago

Incorrect results when a grounded (no variables) spatial function occurs in the SELECT clause in combination with FILTER NOT EXISTS patterns in the WHERE clause

Reported by: charnik Owned by: charnik
Priority: major Milestone: Strabon v3.3
Component: generaldb Version: 3.2.10
Keywords: SELECT clause, FILTER NOT EXISTS, no variables, variables, grounded spatial expresion Cc:

Description

The following query returns a value for variable ?p, but no value for ?srid.

PREFIX geo: <http://www.opengis.net/ont/geosparql#>
PREFIX geof: <http://www.opengis.net/def/function/geosparql/>
PREFIX strdf: <http://strdf.di.uoa.gr/ontology#>

SELECT (geof:getSRID("POINT(37 23)"^^geo:wktLiteral) as ?srid) (geo:point as ?p)
WHERE {
 FILTER NOT EXISTS {<http://ex.org/a> <http://ex.org/b> <http://ex.org/c>}
}

Change History

comment:1 Changed 3 years ago by charnik

  • Owner changed from pyravlos-team to charnik
  • Status changed from new to assigned

comment:2 Changed 3 years ago by charnik

The problem occurs because the optimizer produces such plans as the following, which have ignored the expression for variable srid from the Extensions list.

QueryRoot
   Projection
      ProjectionElemList
         ProjectionElem "srid"
         ProjectionElem "p"
      Extension
         ExtensionElem (p)
            ValueConstant (value=http://www.opengis.net/ont/geosparql#point)
         Filter
            Not
               Exists
                  GeneralDBSelectQuery
                     GeneralDBJoinItem b0 triples_7 b0
                        GeneralDBSqlEq
                           GeneralDBRefIdColumn b0.subj (name=-const-1, value=http://ex.org/a)
                           GeneralDBNumberValue 5
                        GeneralDBSqlEq
                           GeneralDBRefIdColumn b0.obj (name=-const-3, value=http://ex.org/c)
                           GeneralDBNumberValue 9
            SingletonSet

In fact, such an expression has been pushed into the database (after all, we do not have any aggregate function).

SELECT (ST_SRID( ST_GeomFromText('POINT (37 23)',84000)))
FROM (SELECT 0 AS ctx, 0 AS subj, 0 AS pred, 0 AS obj  
WHERE 1=0) b0
WHERE b0.subj =  '5' 
 AND b0.obj =  '9' 

Therefore, the expression is evaluated in the database, but since we do not have any bindings returned, the result of this expression is not carried upwards in Java.

We should not push grounded expressions (i.e., expressions containing only constants) in the database, right? In these cases, we do not have anything to win from evaluating such expressions in the database.

comment:3 Changed 3 years ago by charnik

This bug was addressed in changeset 1391:66958cde6661, by checking whether expressions in SELECT clauses are grounded, and in such cases not evaluating them in the database.

However, there are two issues with this approach:

  1. If such expressions contain strdf:buffer, then currently, we have no way to do the computation both in meters and in degrees using JTS. JTS provides only one version and from what I have seen, computation is done in meters. I think that the same applies also to other functions that involve units of measurements, such as distance.
  2. I am not 100% sure whether there are any drawbacks with this approach. For example, what is going to happen when joining the result of such kind of grounded expressions with a value from the database? Are there such cases? In the same SELECT clause, I think that is not possible, but is it possible to have a subquery with grounded expressions and pushed the result for evaluation to the database, if such result is present in an expression in the outer SELECT query? We have to check how subqueries are evaluated.

Therefore, for the above reasons, I have reverted (see changeset 1420:37792dd7041b) the behavior to the previous one. It can be enabled back by simply uncommenting the following "if" statement from file "GeneralDBSelectQueryOptimizer.java

if (expr instanceof FunctionCall && !isFuncExprGrounded(expr))

In conclusion, dummy queries with FILTER NOT EXISTS and grounded spatial expressions in the SELECT clause will not be evaluated correctly (no results seen in the output). We will live with that for the time being.

Note: See TracTickets for help on using tickets.