Should be fixed with http://svn.apache.org/r1497805
best
Rupert
On Fri, Jun 28, 2013 at 4:36 PM, Rupert Westenthaler
<rupert.westentha...@gmail.com> wrote:
> ok, now I understand. I will look into it.
>
> best
> Rupert
>
> On Fri, Jun 28, 2013 at 4:27 PM, Reto Bachmann-Gmür <r...@wymiwyg.com> wrote:
>> Hi Rupert,
>>
>> I do not understand your example. The "bNode" and "bNodeClone" are not
>>> the same. Even that your force them to return the same hashCode, they
>>> are in fact different BNode instances and therefore MUST NOT be
>>> treated as the same Resource in a Graph.
>>>
>>
>> No, Two BNode are equals if the equals method returns true. This is
>> trivially the case when they are same instance but this doesn't need to be
>> the case. They can well internally have an ID mapping to an id of the
>> backend.
>>
>>
>>>
>>> AFAIK Clerezza does not support "ids" for BNodes, but relies on
>>> "identity" (instance equality - bnode1 == bnode2). So based on that
>>> "bode" and "bNodeClone" created by the provided test case are NOT
>>> equals, but in fact different resources.
>>>
>>
>> No clerezza is defined by it's api, so any bnode subclass qualifies as
>> bnode. The above would be the case if and only is the bnode api would
>> specify that equals has to return true if and only if it's the same object
>> instance.
>>
>>
>>>
>>> What this means for the assertions in the provided test case is
>>> described in detail in the following statements.
>>>
>>> mGraph.add(new TripleImpl(bNode, uriRef1, uriRef2));
>>> mGraph.add(new TripleImpl(bNodeClone, uriRef2, uriRef3));
>>>
>>> bNode and bNodeClone are different resources
>>>
>>> NonLiteral bNodeBack = mGraph.filter(null, uriRef1,
>>> uriRef2).next().getSubject();
>>> Assert.assertEquals("The bnode we get back is not equals to
>>> the one we added", bNode, bNodeBack);
>>>
>>> "bNodeBack" is equals to "bNode"
>>>
>>> NonLiteral bNodeBack2 = mGraph.filter(null, uriRef2,
>>> uriRef3).next().getSubject();
>>>
>>> "bNodeBack2" is equals to "bNodeClone"
>>>
>>> Assert.assertEquals("The returnned bnodes are no longer
>>> equals", bNodeBack, bNodeBack2);
>>>
>>> but "bNodeBack" and "bNodeBack2" are not equals as "bNode" and
>>> "bNodeClone" are not.
>>>
>>> Assert.assertTrue("Not finding a triple when searching with
>>> equal bNode", mGraph.filter(bNodeBack, uriRef2, null).hasNext());
>>>
>>> also this is expected to be empty, because there is no triple such as
>>> "bNode", "uriRef2", "*"
>>>
>>>
>>> BTW: if you you change bNodeClone to "bNodeClone = bnode" the test
>>> runs fine (as expected)
>>>
>>> This does not mean that there is no issues related to bNodes. It just
>>> means that the provided example does not show the problem.
>>>
>>
>> It does show the problem. And it's a very real problem because a clerezza
>> wrapper from some backend will not create inmenory mapping from orignal
>> bnodes to clerezza bnodes but simply wrap the bnodes and implement hashcode
>> and equals in a constistent fashion. So the test I added must pass for
>> conformant implementation.
>>
>> Cheers,
>> Reto
>>
>>
>>
>>
>>>
>>> best
>>> Rupert
>>>
>>>
>>>
>>> On Fri, Jun 28, 2013 at 12:37 PM, Reto Bachmann-Gmür <r...@wymiwyg.com>
>>> wrote:
>>> > Hi Rupert,
>>> >
>>> > I've added a commented out failing test for
>>> > STANBOL-1130<https://issues.apache.org/jira/browse/STANBOL-1130>
>>> > .
>>> >
>>> > Cheers,
>>> > Reto
>>> >
>>> >
>>> > On Fri, Jun 28, 2013 at 12:23 PM, Rupert Westenthaler <
>>> > rupert.westentha...@gmail.com> wrote:
>>> >
>>> >> Hi Reto,
>>> >>
>>> >> I changed the comparator implementation of the IndexMGraph some weeks
>>> >> ago, because the old code was not working when different Resource
>>> >> implementations where mixed within the same graph. So this indicates
>>> >> indeed a bug.
>>> >>
>>> >> Can you add a failing unit test for this issue?
>>> >>
>>> >> best
>>> >> Rupert
>>> >>
>>> >>
>>> >> On Fri, Jun 28, 2013 at 12:07 PM, Reto Bachmann-Gmür <r...@apache.org>
>>> >> wrote:
>>> >> > Hello,
>>> >> >
>>> >> > Investigating why recipe-exmpansion in no longer working I found that
>>> it
>>> >> > seems to be an issue with the IndexedMGarph as things work when using
>>> >> > SimleMGraph instead. It used to work till a couple of week ago.
>>> >> >
>>> >> > Now it seems that a bnode is no longer identical to itself when
>>> occuring
>>> >> in
>>> >> > different triples. While I'm investigating further I though I ask if
>>> >> > someone else noticed problems like that.
>>> >> >
>>> >> > Cheers,
>>> >> > Reto
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> | Rupert Westenthaler rupert.westentha...@gmail.com
>>> >> | Bodenlehenstraße 11 ++43-699-11108907
>>> >> | A-5500 Bischofshofen
>>> >>
>>>
>>>
>>>
>>> --
>>> | Rupert Westenthaler rupert.westentha...@gmail.com
>>> | Bodenlehenstraße 11 ++43-699-11108907
>>> | A-5500 Bischofshofen
>>>
>
>
>
> --
> | Rupert Westenthaler rupert.westentha...@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
--
| Rupert Westenthaler rupert.westentha...@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
