[
https://issues.apache.org/jira/browse/JENA-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17155471#comment-17155471
]
Andy Seaborne edited comment on JENA-1936 at 7/10/20, 3:21 PM:
---------------------------------------------------------------
SPARQL isn't a factor though I guess the execution order was different in 3.01,
but I can't remember why that might be.
The value if hexBinary or base64binary is a {{byte[]}} and two {{byte[]}} with
the same bytes are not {{equals}}. For every other datatype the value is
value-equality.
For nodes which do not conform to the lexical space of the datatype, the index
is the lexical form (so 'A' works).
This is only about default graphmem. All other storage graphs are term-based.
(And the command line SPARQL query tool uses {{DatasetGraphInMemory}}.)
{noformat}
static
public void binary() {
String DT = "hexBinary";
Node s = SSE.parseNode(":s");
Node p = SSE.parseNode(":p");
Node n1 = SSE.parseNode("''^^xsd:"+DT);
Node n2 = SSE.parseNode("''^^xsd:"+DT);
Graph graph = GraphFactory.createDefaultGraph();
//Graph graph =
DatasetFactory.createTxnMem().getDefaultModel().getGraph();
graph.add(Triple.create(s, p, n1));
// find will choose the o index if object set or if predicate-object
set.
System.out.println("? ? ? :: "+graph.find(null, null, null).toList());
System.out.println("? ? n1 :: "+graph.find(null, null, n1).toList());
System.out.println("? ? n2 :: "+graph.find(null, null, n2).toList());
System.out.println("? p n1 :: "+graph.find(null, p, n1).toList());
System.out.println("? p n2 :: "+graph.find(null, p, n2).toList());
// Subject set - will use subject index and succeed.
// System.out.println("s ? n1 :: "+graph.find(s, null, n1).toList());
// System.out.println("s ? n2 :: "+graph.find(s, null, n2).toList());
// System.out.println("s p n1 :: "+graph.find(s, p, n1).toList());
// System.out.println("s p n2 :: "+graph.find(s, p, n2).toList());
}
{noformat}
was (Author: andy.seaborne):
SPARQL isn't a fact though I guess the execution order was different in 3.01,
but I can't rmember why that might be.
The value if hexBinary or base64binary is a {{byte[]}} and two {{byte[]}} with
the same bytes are not {{equals}}. For every other datatype the value is
value-equality.
For nodes which do not conform to the lexical space of the datatype, the index
is the lexical form (so 'A' works).
This is only about default graphmem. All other storage graphs are term-based.
(And the command line SPARQL query tool uses {{DatasetGraphInMemory}}.)
{noformat}
static
public void binary() {
String DT = "hexBinary";
Node s = SSE.parseNode(":s");
Node p = SSE.parseNode(":p");
Node n1 = SSE.parseNode("''^^xsd:"+DT);
Node n2 = SSE.parseNode("''^^xsd:"+DT);
Graph graph = GraphFactory.createDefaultGraph();
//Graph graph =
DatasetFactory.createTxnMem().getDefaultModel().getGraph();
graph.add(Triple.create(s, p, n1));
// find will choose the o index if object set or if predicate-object
set.
System.out.println("? ? ? :: "+graph.find(null, null, null).toList());
System.out.println("? ? n1 :: "+graph.find(null, null, n1).toList());
System.out.println("? ? n2 :: "+graph.find(null, null, n2).toList());
System.out.println("? p n1 :: "+graph.find(null, p, n1).toList());
System.out.println("? p n2 :: "+graph.find(null, p, n2).toList());
// Subject set - will use subject index and succeed.
// System.out.println("s ? n1 :: "+graph.find(s, null, n1).toList());
// System.out.println("s ? n2 :: "+graph.find(s, null, n2).toList());
// System.out.println("s p n1 :: "+graph.find(s, p, n1).toList());
// System.out.println("s p n2 :: "+graph.find(s, p, n2).toList());
}
{noformat}
> Query returned results with 3.0.1, does not return with 3.16.0-SNAPSHOT
> -----------------------------------------------------------------------
>
> Key: JENA-1936
> URL: https://issues.apache.org/jira/browse/JENA-1936
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
> Affects Versions: Jena 3.16.0
> Reporter: Martynas Jusevičius
> Priority: Major
>
> This query returns results with 3.0.1 but not with 3.16.0-SNAPSHOT:
> {noformat}
> PREFIX cert: <http://www.w3.org/ns/auth/cert#>
> SELECT *
> {
> ?webid cert:key [
> cert:modulus
> "a0a15887e44bab6c36862c54771324604d55bda36d2c015cbad2dc6528b5c33e01103cfbeb9c8b8a22e7d74c66fc950f0f82616412fc8c5028e9384651d4f40c7c1d40c9b861191894537d719a5098c1eea5521d2273613cdd91563205fa3e25f99ecacc04824b07449087499a6a53a81a6b1d838406a97a0f7d691257fd4cd10662afbdebdbddacb9631a255930470e866949b5e8684b38d82141263f5c6c029f716a026c31f139b3f1164cfc1865283256f75cad0ee23318ca2323bc37704124f4d17f77763314c2ed92a71b2df5a960be83acb83285e1eda6bfb5af6f3f1342487ef961cc96b3680f544626f88c611fbcb2e03c06b261b838f72ecac59831"^^<http://www.w3.org/2001/XMLSchema#hexBinary>
>
> ] .
> }{noformat}
> Reproducible test case:
> [https://github.com/namedgraph/jena-test/blob/master/src/test/java/WebIDCertTest.java]
> This might or might not be related to another issue that affects both 3.0.1
> and 3.16.0-SNAPSHOT - it seems that {{xsd:hexBinary}} literals are not
> matched in a BGP:
>
> [https://github.com/namedgraph/jena-test/blob/master/src/test/java/SPARQLTest.java#L55]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)