You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Claude Warren <cl...@xenei.com> on 2013/10/03 21:55:03 UTC

GraphMemTest question

Quick question:

I find a test called testUnnecessaryMatches() that verifies that when the
graph.find() method is called it does not call node_URI.matches()

patterns checked are (Node_URI, ANY, ANY )
patterns checked are (ANY, Node_URI,  ANY )
patterns checked are (ANY, ANY, Node_URI )

My question is:

Is this a general restriction (i.e. all graph implementations should meet
this) or specific to the memory graph?

Claude
-- 
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren

Re: GraphMemTest question

Posted by Claude Warren <cl...@xenei.com>.
Just so we can be clear on what I am working on.  I am taking the
interfaces and creating contract tests for them.  These are a bit more
complex than standard unit tests.  For example the Graph interface contract
says that when a triple is deleted the listener is notified.  The contract
also specifies that the listener should be notified immediately after the
add but before the transaction finished.  If the transaction is rolled back
the back out commands must also be sent to the listener.

Anyway, I am creating contract tests for the interfaces and leaving the
anything not covered by the contract test in the specific implementation
classes.

I am also using the junit-contract suite for some the testing in the model
framework (https://github.com/Claudenw/junit-contracts) where I need to
include the contract tests for multiple interfaces in one suite.

I was most of the way through the model tests when I ran into a problem and
had to take a break to write the junit-contract test runner.  I am back on
track now and pushing ahead.  I should have a major checkin on the branch
in the next few days.

Claude


On Fri, Oct 4, 2013 at 2:09 PM, Andy Seaborne <an...@apache.org> wrote:

> On 04/10/13 13:03, Chris_Dollin wrote:
>
>> Andy wrote:
>>
>>  On Thursday, October 03, 2013 08:55:03 PM Claude Warren wrote:
>>>>
>>>>> I find a test called testUnnecessaryMatches() that verifies that when
>>>>> the
>>>>> graph.find() method is called it does not call node_URI.matches()
>>>>>
>>>>> patterns checked are (Node_URI, ANY, ANY )
>>>>> patterns checked are (ANY, Node_URI,  ANY )
>>>>> patterns checked are (ANY, ANY, Node_URI )
>>>>>
>>>>> My question is:
>>>>>
>>>>> Is this a general restriction (i.e. all graph implementations should
>>>>> meet
>>>>> this) or specific to the memory graph?
>>>>>
>>>>
>>>> I'm pretty sure that it's specific to GraphMem and that's it's checking
>>>> that Mem does the work itself rather than relying on GraphBase.
>>>>
>>>> [If it had been graph-implementation-agnostic I'd have put it in the
>>>>
>>>>    test-any-graph tests. I hope. If my memory serves.]
>>>>
>>>> Chris
>>>>
>>>
>>> Chris - how much of match* (Node and Triple) was for QueryHandler ? or
>>> is specific to GraphMem?
>>>
>>
>> Oh, good point -- it's there for the QueryHandler stuff, which GraphMem
>> knew about and optimised the general case. Well, maybe it optimised,
>> there wasn't any actual testing done there.
>>
>>  If it's just for GraphMem now, one option is to move the code to a class
>>> of function in chhj.mem as "boolean matches(Node, Node)" etc and gently
>>> make Node / Triple have a smaller interface.
>>>
>>
>> If it's not used elsewjere -- which seems likely -- yes, that's a good
>> idea.
>>
>
> I may have a go at some gardening sometime (JENA-554). At a very quick
> glance, some of the GraphMem related classes may have only been used by the
> QueryHandler subsystem.
>
>         Andy
>
>
>> Good catch.
>>
>> Chris
>>
>>
>


-- 
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren

Re: GraphMemTest question

Posted by Andy Seaborne <an...@apache.org>.
On 04/10/13 13:03, Chris_Dollin wrote:
> Andy wrote:
>
>>> On Thursday, October 03, 2013 08:55:03 PM Claude Warren wrote:
>>>> I find a test called testUnnecessaryMatches() that verifies that when the
>>>> graph.find() method is called it does not call node_URI.matches()
>>>>
>>>> patterns checked are (Node_URI, ANY, ANY )
>>>> patterns checked are (ANY, Node_URI,  ANY )
>>>> patterns checked are (ANY, ANY, Node_URI )
>>>>
>>>> My question is:
>>>>
>>>> Is this a general restriction (i.e. all graph implementations should meet
>>>> this) or specific to the memory graph?
>>>
>>> I'm pretty sure that it's specific to GraphMem and that's it's checking
>>> that Mem does the work itself rather than relying on GraphBase.
>>>
>>> [If it had been graph-implementation-agnostic I'd have put it in the
>>>
>>>    test-any-graph tests. I hope. If my memory serves.]
>>>
>>> Chris
>>
>> Chris - how much of match* (Node and Triple) was for QueryHandler ? or
>> is specific to GraphMem?
>
> Oh, good point -- it's there for the QueryHandler stuff, which GraphMem
> knew about and optimised the general case. Well, maybe it optimised,
> there wasn't any actual testing done there.
>
>> If it's just for GraphMem now, one option is to move the code to a class
>> of function in chhj.mem as "boolean matches(Node, Node)" etc and gently
>> make Node / Triple have a smaller interface.
>
> If it's not used elsewjere -- which seems likely -- yes, that's a good idea.

I may have a go at some gardening sometime (JENA-554). At a very quick 
glance, some of the GraphMem related classes may have only been used by 
the QueryHandler subsystem.

	Andy

>
> Good catch.
>
> Chris
>


Re: GraphMemTest question

Posted by Chris_Dollin <eh...@gmail.com>.
Andy wrote:

> > On Thursday, October 03, 2013 08:55:03 PM Claude Warren wrote:
> >> I find a test called testUnnecessaryMatches() that verifies that when the
> >> graph.find() method is called it does not call node_URI.matches()
> >> 
> >> patterns checked are (Node_URI, ANY, ANY )
> >> patterns checked are (ANY, Node_URI,  ANY )
> >> patterns checked are (ANY, ANY, Node_URI )
> >> 
> >> My question is:
> >> 
> >> Is this a general restriction (i.e. all graph implementations should meet
> >> this) or specific to the memory graph?
> > 
> > I'm pretty sure that it's specific to GraphMem and that's it's checking
> > that Mem does the work itself rather than relying on GraphBase.
> > 
> > [If it had been graph-implementation-agnostic I'd have put it in the
> > 
> >   test-any-graph tests. I hope. If my memory serves.]
> > 
> > Chris
> 
> Chris - how much of match* (Node and Triple) was for QueryHandler ? or
> is specific to GraphMem?

Oh, good point -- it's there for the QueryHandler stuff, which GraphMem
knew about and optimised the general case. Well, maybe it optimised,
there wasn't any actual testing done there.

> If it's just for GraphMem now, one option is to move the code to a class
> of function in chhj.mem as "boolean matches(Node, Node)" etc and gently
> make Node / Triple have a smaller interface.

If it's not used elsewjere -- which seems likely -- yes, that's a good idea.

Good catch.

Chris


Re: GraphMemTest question

Posted by Andy Seaborne <an...@apache.org>.
On 04/10/13 06:49, Chris_Dollin wrote:
> On Thursday, October 03, 2013 08:55:03 PM Claude Warren wrote:
>
>> I find a test called testUnnecessaryMatches() that verifies that when the
>> graph.find() method is called it does not call node_URI.matches()
>>
>> patterns checked are (Node_URI, ANY, ANY )
>> patterns checked are (ANY, Node_URI,  ANY )
>> patterns checked are (ANY, ANY, Node_URI )
>>
>> My question is:
>>
>> Is this a general restriction (i.e. all graph implementations should meet
>> this) or specific to the memory graph?
>
> I'm pretty sure that it's specific to GraphMem and that's it's checking
> that Mem does the work itself rather than relying on GraphBase.
>
> [If it had been graph-implementation-agnostic I'd have put it in the
>   test-any-graph tests. I hope. If my memory serves.]
>
> Chris
>

Chris - how much of match* (Node and Triple) was for QueryHandler ? or 
is specific to GraphMem?

If it's just for GraphMem now, one option is to move the code to a class 
of function in chhj.mem as "boolean matches(Node, Node)" etc and gently 
make Node / Triple have a smaller interface.

It may save time for Claude as well.

	Andy


Re: GraphMemTest question

Posted by Chris_Dollin <eh...@gmail.com>.
On Thursday, October 03, 2013 08:55:03 PM Claude Warren wrote:

> I find a test called testUnnecessaryMatches() that verifies that when the
> graph.find() method is called it does not call node_URI.matches()
> 
> patterns checked are (Node_URI, ANY, ANY )
> patterns checked are (ANY, Node_URI,  ANY )
> patterns checked are (ANY, ANY, Node_URI )
> 
> My question is:
> 
> Is this a general restriction (i.e. all graph implementations should meet
> this) or specific to the memory graph?

I'm pretty sure that it's specific to GraphMem and that's it's checking
that Mem does the work itself rather than relying on GraphBase.

[If it had been graph-implementation-agnostic I'd have put it in the
 test-any-graph tests. I hope. If my memory serves.]

Chris