On 07/07/17 20:29, Daan Reid wrote:
Hi all,
After upgrading to Jena 3.2 recently, we encountered the issue
referenced here:
https://issues.apache.org/jira/browse/JENA-1370
Daan - what did you upgrade from?
(You also mention TDB there)
In short, a graph Delta, when adding a triple with a double value
property that is semantically the same but lexically different to a
triple already in the graph causes what is in my opinion incorrect
behaviour: The triple is placed in the deletions list and not in the
additions list, in essence removing it from the graph even though it
should still be in there.
So for example if I take a Delta with graph base containing `:s :p
-1.700000e+00 .`
and then clear it and add the triple `:s :p -1.7E0 .`, the resulting
Delta will have a set of deletions containing the original triple, and
an empty list of additions.
As far as I can tell this is because Delta uses .contains() to check its
additions and deletions, and for the volatile GraphMem we use, the
literals are checked for lexical instead of semantic equality, and this
causes inconsistencies.
I would appreciate any and all help with this.
Yes - it looks like that is the problem. It is compounded by the fact
that it uses GraphMem internally for additions and deletions which
impacts Delta.find() so even if the input graph is a term-equity-graph
then find() is still doing some value matching.
I would have thought that the behaviour should be term-based throughout
but what use cases are there for using Delta?
A workaround is to use a term-based graphs
e.g. DatasetGraphFactory.createTxnMem().getDefaultGraph();
which needs taking copy of Delta and replacing the additions and
deletions graphs as well as the base graph.
Long term, Delta could add a value-to-term wrapper to work on term
equality only.
Andy
Regards,
Daan Reid
Drugis project - https://drugis.org
