Ticket #53 (closed defect: fixed)

Opened 4 years ago

Last modified 3 years ago

CONSTRUCT and DESCRIBE queries that include UNION in WHERE clause, don't return results.

Reported by: elaiza Owned by: charnik
Priority: minor Milestone: Strabon v3.3
Component: generaldb Version: all
Keywords: Cc:

Description

An exception is thrown when a CONSTRUCT or DESCRIBE query that includes UNION (one or more) in WHERE clause is made, and the query doesn't return any results.

For example, the below CONSTRUCT query in the attached dataset:

PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
PREFIX skos:<http://www.w3.org/2004/02/skos/core#>

CONSTRUCT { ?term skos:broader ?related }
WHERE
{

{ ?term skos:prefLabel ?label . ?term skos:broader ?related }

UNION

{ ?term rdfs:label ?label . ?term skos:broader ?related }

}

Should return:
<http://www.eionet.europa.eu/gemet/concept/11> <http://www.w3.org/2004/02/skos/core#broader> <http://www.eionet.europa.eu/gemet/concept/2457> .
<http://www.eionet.europa.eu/gemet/concept/20> <http://www.w3.org/2004/02/skos/core#broader> <http://www.eionet.europa.eu/gemet/concept/6033> .
<http://www.eionet.europa.eu/gemet/concept/72> <http://www.w3.org/2004/02/skos/core#broader> <http://www.eionet.europa.eu/gemet/concept/11813> .

Attachments

sampleDataset.n3 (793 bytes) - added by elaiza 4 years ago.
The sample dataset

Change History

Changed 4 years ago by elaiza

The sample dataset

comment:1 Changed 3 years ago by charnik

  • Milestone set to Strabon v3.3

comment:2 Changed 3 years ago by charnik

This bug affects also SELECT queries. In particular, they hit the same exception: "java.lang.IllegalArgumentException?: Node is not a child node: GeneralDBBNodeColumn u4.l3pred (name=-const-3, value=​http://www.w3.org/2000/01/rdf-schema#label)".

Interestingly enough, this query returns a lot of results when evaluated on DBpedia: http://dbpedia.org/sparql.

comment:3 Changed 3 years ago by charnik

Interesting thing: For SELECT queries, if your project only on the ?term and ?related, it works!
I think that this bug might be on sesame's part, unfortunately.

comment:4 Changed 3 years ago by charnik

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

comment:5 Changed 3 years ago by charnik

  • Status changed from assigned to closed
  • Version set to all
  • Resolution set to fixed

Fixed in changeset 1367:87245de36992.

The error is quite silly and I don't think that it has been solved at all. However, I tried to suppress it. It's better to suppress a behavior for which you are 100% sure that will lead to an exception (think of it as a SIGSEGV), rather than letting it blow things up. Let me explain.

The problem is in UnaryGeneralDBOperator.replaceChildNode() method. The "else" part calls its super overriding method which just throws an exception. At the first place, either
1) the super method shouldn't be ever called from UnaryGeneralDBOperator.replaceChildNode(), or
2) some previous operation should have provided for that case.

For the first case, and since this belongs to the UnaryGeneralDBOperator part, I think that something is missing from our side. Since I do not know what exactly that is, I just suppress the exception. By doing so, the test case (query, data) we have above works perfectly.

For the second, it's certainly a bug in Sesame's code. This occurs after a TupleExpr? has been computed and method GeneralDBVarColumnLookupOptimizer.optimize() is called on it. In that call, the produced TupleExpr? is traversed and re-organized. In the context of this bug, the optimize() method tries to remove any joins that are irrelevant or useless to the final query. For example, when you project on a predicate, it is certain that no joins are needed with bnodes, datatypes, labels tables, and so on. Optimize() takes care of the removal of such joins.

It is important to mention that almost all classes in generaldb.algebra and generaldb.algebra.base extend QueryModelNodeBase? or some other subclass of it. The default behavior of QueryModelNodeBase?.replaceChildNode() is to throw the exception

IllegalArgumentException?("Node is not a child node: " + current)

and while I didn't look through all the subclasses, most or all of them they call it at some point. Therefore, this error might arise in other cases as well.

Anyway, for this bug, I just commented the corresponding call and log a WARN message.

Note: See TracTickets for help on using tickets.