You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@seaborne.org> on 2017/07/09 13:08:07 UTC
GraphTripleStoreMem
Chris,
I'm engaged in some code-archaeology :-) (after looking at the message
about Delta which I'm kind of lost on). I'm hoping you can recall what
the situation is for some classes.
GraphMem uses GraphTripleStoreMem.
But there are some classes that look quite similar:
GraphTripleStore -- GraphTripleStoreMem
NodeToTriplesMap -- NodeToTriplesMapMem
(are there any others of this kind?)
Are the left-hand ones replaced by the right-hand ones?
The left-hand ones have some tests - the right-hand ones don't have
direct tests although given that they are behind GraphMem, they get a
lot of tests anyway.
Andy
Re: GraphTripleStoreMem
Posted by Andy Seaborne <an...@apache.org>.
I unsubtly removed the LHS ones and didn't run into any substantial
problems - some test cleaning up. It seems that where the LHS is tested
and nearly perfectly can be retargetted at the RHS.
Andy
On 10/07/17 15:09, Andy Seaborne wrote:
> Relatedly:
>
> https://github.com/afs/jena-reports/blob/master/src/graphmem/GraphPlain.java
>
>
> A (prototype of a) graph adapter that turns a value-based graph into a
> term based graph.
>
> Something like Delta needs term equality because it tracks changes.
>
> The alternative is having value-based graph store triples using a
> S-P-value only once.
>
> Andy
>
> On 09/07/17 15:58, Chris Dollin wrote:
>> Hi Andy
>>
>> My tattered recollection is that originally there was only
>> GraphTripleStore (and NodeToTriplesMap). Then we (for some
>> value of "we") realised that the code made assumptions that
>> were false for non-memory (so, at the time, RDB) triples, so
>> the existing code was renamed to have a Mem suffix and the
>> non-Mem code had the assumptions removed.
>>
>> Alas, I cannot recall what the assumptions were ... maybe
>> to do with whether the value of a literal was always there
>> (in the Mem case) or not (in the non-Mem case).
>>
>> I suspect then changes were made to non-Mem code that
>> could have been, but were not, shared with Mem code.
>>
>> I don't think we can simply eliminate the left-hand classes
>> in favour of the right-hand ones in case there's code which
>> (explicitly or implicitly) expects the Mem classes.
>>
>> I have another look tomorrow.
>>
>> Chris
>>
>>
>>
>> On 9 July 2017 at 14:08, Andy Seaborne <an...@seaborne.org> wrote:
>>
>>> Chris,
>>>
>>> I'm engaged in some code-archaeology :-) (after looking at the message
>>> about Delta which I'm kind of lost on). I'm hoping you can recall
>>> what the
>>> situation is for some classes.
>>>
>>> GraphMem uses GraphTripleStoreMem.
>>>
>>> But there are some classes that look quite similar:
>>>
>>> GraphTripleStore -- GraphTripleStoreMem
>>> NodeToTriplesMap -- NodeToTriplesMapMem
>>>
>>> (are there any others of this kind?)
>>>
>>> Are the left-hand ones replaced by the right-hand ones?
>>>
>>> The left-hand ones have some tests - the right-hand ones don't have
>>> direct
>>> tests although given that they are behind GraphMem, they get a lot of
>>> tests
>>> anyway.
>>>
>>> Andy
>>>
>>
>>
>>
Re: GraphTripleStoreMem
Posted by Andy Seaborne <an...@apache.org>.
Relatedly:
https://github.com/afs/jena-reports/blob/master/src/graphmem/GraphPlain.java
A (prototype of a) graph adapter that turns a value-based graph into a
term based graph.
Something like Delta needs term equality because it tracks changes.
The alternative is having value-based graph store triples using a
S-P-value only once.
Andy
On 09/07/17 15:58, Chris Dollin wrote:
> Hi Andy
>
> My tattered recollection is that originally there was only
> GraphTripleStore (and NodeToTriplesMap). Then we (for some
> value of "we") realised that the code made assumptions that
> were false for non-memory (so, at the time, RDB) triples, so
> the existing code was renamed to have a Mem suffix and the
> non-Mem code had the assumptions removed.
>
> Alas, I cannot recall what the assumptions were ... maybe
> to do with whether the value of a literal was always there
> (in the Mem case) or not (in the non-Mem case).
>
> I suspect then changes were made to non-Mem code that
> could have been, but were not, shared with Mem code.
>
> I don't think we can simply eliminate the left-hand classes
> in favour of the right-hand ones in case there's code which
> (explicitly or implicitly) expects the Mem classes.
>
> I have another look tomorrow.
>
> Chris
>
>
>
> On 9 July 2017 at 14:08, Andy Seaborne <an...@seaborne.org> wrote:
>
>> Chris,
>>
>> I'm engaged in some code-archaeology :-) (after looking at the message
>> about Delta which I'm kind of lost on). I'm hoping you can recall what the
>> situation is for some classes.
>>
>> GraphMem uses GraphTripleStoreMem.
>>
>> But there are some classes that look quite similar:
>>
>> GraphTripleStore -- GraphTripleStoreMem
>> NodeToTriplesMap -- NodeToTriplesMapMem
>>
>> (are there any others of this kind?)
>>
>> Are the left-hand ones replaced by the right-hand ones?
>>
>> The left-hand ones have some tests - the right-hand ones don't have direct
>> tests although given that they are behind GraphMem, they get a lot of tests
>> anyway.
>>
>> Andy
>>
>
>
>
Re: GraphTripleStoreMem
Posted by Chris Dollin <ch...@epimorphics.com>.
Hi Andy
My tattered recollection is that originally there was only
GraphTripleStore (and NodeToTriplesMap). Then we (for some
value of "we") realised that the code made assumptions that
were false for non-memory (so, at the time, RDB) triples, so
the existing code was renamed to have a Mem suffix and the
non-Mem code had the assumptions removed.
Alas, I cannot recall what the assumptions were ... maybe
to do with whether the value of a literal was always there
(in the Mem case) or not (in the non-Mem case).
I suspect then changes were made to non-Mem code that
could have been, but were not, shared with Mem code.
I don't think we can simply eliminate the left-hand classes
in favour of the right-hand ones in case there's code which
(explicitly or implicitly) expects the Mem classes.
I have another look tomorrow.
Chris
On 9 July 2017 at 14:08, Andy Seaborne <an...@seaborne.org> wrote:
> Chris,
>
> I'm engaged in some code-archaeology :-) (after looking at the message
> about Delta which I'm kind of lost on). I'm hoping you can recall what the
> situation is for some classes.
>
> GraphMem uses GraphTripleStoreMem.
>
> But there are some classes that look quite similar:
>
> GraphTripleStore -- GraphTripleStoreMem
> NodeToTriplesMap -- NodeToTriplesMapMem
>
> (are there any others of this kind?)
>
> Are the left-hand ones replaced by the right-hand ones?
>
> The left-hand ones have some tests - the right-hand ones don't have direct
> tests although given that they are behind GraphMem, they get a lot of tests
> anyway.
>
> Andy
>
--
"What I don't understand is this ..." Trevor Chaplin, /The Beiderbeck
Affair/
Epimorphics Ltd, http://www.epimorphics.com
Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20
6PT
Epimorphics Ltd. is a limited company registered in England (number 7016688)