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/07 10:10:58 UTC
graph remove( node, node, node) side effects?
When calling graph.remove( A , B, C )
should the graphListener be informed of delete( Triple<A, B, C> ) as well
as the graph event ( remove A B C )? I am assuming that the answer is yes
always.
Functionally, what is the difference between remove( A, B, C ) and delete
(Triple<A,B,C>)?
I managed to get the contract tests for the graph complete yesterday and
found that different implementations of graph seem to handle this
differently. I don't recall which ones right at the moment. I will double
check when I get home.
Claude.
--
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: graph remove( node, node, node) side effects?
Posted by Andy Seaborne <an...@apache.org>.
On 08/10/13 15:38, Chris Dollin wrote:
> On Tuesday, October 08, 2013 03:14:49 PM Claude Warren wrote:
>> So should the graph throw an exception if Graph.remove( Triple.ANY ) is
>> executed? Should it throw an exception if the triple is not concrete (no
>> wildcards).
>
> I think the time for that "should" is long past. It hasn't thrown an exception
> for doing that for the past ten years; there may be code out there that
> relies on the current relaxed approach. It seems to me that it's a non-
> problem; document it and move on.
It's harmless - there is nothing to delete.
(Corner use case: The basic machinary like graph etc can be used for
generalized non-RDF structures which might conceivably put Node.ANY into
a graph.)
Andy
>
> Chris
>
Re: Re: Re: Re: graph remove( node, node, node) side effects?
Posted by Chris Dollin <ch...@epimorphics.com>.
On Tuesday, October 08, 2013 03:14:49 PM Claude Warren wrote:
> So should the graph throw an exception if Graph.remove( Triple.ANY ) is
> executed? Should it throw an exception if the triple is not concrete (no
> wildcards).
I think the time for that "should" is long past. It hasn't thrown an exception
for doing that for the past ten years; there may be code out there that
relies on the current relaxed approach. It seems to me that it's a non-
problem; document it and move on.
Chris
--
"You're down as expendable. You don't get a weapon." /Dark Lord of Derkholm/
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)
Re: Re: Re: graph remove( node, node, node) side effects?
Posted by Claude Warren <cl...@xenei.com>.
So should the graph throw an exception if Graph.remove( Triple.ANY ) is
executed? Should it throw an exception if the triple is not concrete (no
wildcards).
On Tue, Oct 8, 2013 at 3:11 PM, Chris Dollin
<ch...@epimorphics.com>wrote:
> On Tuesday, October 08, 2013 02:46:13 PM Claude Warren wrote:
> > I was reading the Graph javadoc, which is not specific. I'll update it.
>
> It needs a bit of reading through, I'll grant that.
>
> (That find(S,P,O) does matching is implicit in that it returns an
> iterator, rather than explicitly stated, and one needs to know that
> to know that remove can hence remove multiple things and so
> does pattern-matching itself (if it doesn't jsut delgate to find anyway).)
>
> (Chris)
>
> --
> "You're down as expendable. You don't get a weapon." /Dark Lord of
> Derkholm/
>
> 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)
>
>
--
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: Re: Re: graph remove( node, node, node) side effects?
Posted by Chris Dollin <ch...@epimorphics.com>.
On Tuesday, October 08, 2013 02:46:13 PM Claude Warren wrote:
> I was reading the Graph javadoc, which is not specific. I'll update it.
It needs a bit of reading through, I'll grant that.
(That find(S,P,O) does matching is implicit in that it returns an
iterator, rather than explicitly stated, and one needs to know that
to know that remove can hence remove multiple things and so
does pattern-matching itself (if it doesn't jsut delgate to find anyway).)
(Chris)
--
"You're down as expendable. You don't get a weapon." /Dark Lord of Derkholm/
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)
Re: Re: graph remove( node, node, node) side effects?
Posted by Claude Warren <cl...@xenei.com>.
I was reading the Graph javadoc, which is not specific. I'll update it.
On Tue, Oct 8, 2013 at 2:43 PM, Chris Dollin
<ch...@epimorphics.com>wrote:
> On Tuesday, October 08, 2013 02:13:10 PM Andy Seaborne wrote:
> > On 08/10/13 09:35, Claude Warren wrote:
> > > I have no problem making changes. The problem is I don't know what the
> > > proper action should be, hence all my questions as of late.
> >
> > """
> > If patterns are not allowed I
> > think we should update the docs.
> > """
>
> The documentation and code says that delete(Triple) deletes exactly
> that triple (no matching) and that remove(Node x 3) deletets
> those things that find finds, ie, respects ANY.
>
> Chris
>
> --
> "I know it was late, but Mountjoy never bothers, /Archer's
> Goon/
> so long as it's the full two thousand words."
>
> 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)
>
>
--
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: Re: graph remove( node, node, node) side effects?
Posted by Chris Dollin <ch...@epimorphics.com>.
On Tuesday, October 08, 2013 02:13:10 PM Andy Seaborne wrote:
> On 08/10/13 09:35, Claude Warren wrote:
> > I have no problem making changes. The problem is I don't know what the
> > proper action should be, hence all my questions as of late.
>
> """
> If patterns are not allowed I
> think we should update the docs.
> """
The documentation and code says that delete(Triple) deletes exactly
that triple (no matching) and that remove(Node x 3) deletets
those things that find finds, ie, respects ANY.
Chris
--
"I know it was late, but Mountjoy never bothers, /Archer's Goon/
so long as it's the full two thousand words."
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)
Re: graph remove( node, node, node) side effects?
Posted by Andy Seaborne <an...@apache.org>.
On 08/10/13 09:35, Claude Warren wrote:
> I have no problem making changes. The problem is I don't know what the
> proper action should be, hence all my questions as of late.
"""
If patterns are not allowed I
think we should update the docs.
"""
as we clarify things, then if theer are any outcomes, they can be just done.
(Similarly JENA-557, 540, 539 and any open ended JIRAs -- but then I
have a fixation on closing JIRAs!)
Andy
>
>
> On Tue, Oct 8, 2013 at 9:31 AM, Andy Seaborne <an...@apache.org> wrote:
>
>> On 07/10/13 22:38, Claude Warren wrote:
>>
>>> On Mon, Oct 7, 2013 at 10:11 PM, Andy Seaborne <an...@apache.org> wrote:
>>>
>>> On 07/10/13 09:10, Claude Warren wrote:
>>>>
>>>> When calling graph.remove( A , B, C )
>>>>> should the graphListener be informed of delete( Triple<A, B, C> ) as
>>>>> well
>>>>> as the graph event ( remove A B C )? I am assuming that the answer is
>>>>> yes
>>>>> always.
>>>>>
>>>>>
>>>> Don't know -- what does the code do currently?
>>>>
>>>> It varies depending upon the implementation.
>>>>
>>>
>>>
>>>>
>>>> Functionally, what is the difference between remove( A, B, C ) and
>>>>> delete
>>>>> (Triple<A,B,C>)?
>>>>>
>>>>>
>>>> Javadoc:
>>>> [[
>>>> remove(Node s, Node p, Node o)
>>>> Remove all triples that match by find(s, p, o)
>>>> ]]
>>>>
>>>> Graph.remove is a pattern (Node.ANYs allowed, and nulls),
>>>> Graph.delete(Triple) affects only and exactly that triple, no pattern.
>>>>
>>>
>>>
>>> My reading of the java doc is that I can pass any triple so Graph.delete(
>>> Triple.ANY ) will delete all triples from the grap (extreme example) but
>>> that other patters would also be allowed. If patterns are not allowed I
>>> think we should update the docs. If they are allowed it sounds like the
>>> difference is the use of the triple or the 3 nodes.
>>>
>>
>> Claude,
>>
>> You have commit access on the codebase so do go ahead and fix things that
>> you find need fixing.
>>
>> Andy
>>
>>
>> I managed to get the contract tests for the graph complete yesterday and
>>>>
>>>>> found that different implementations of graph seem to handle this
>>>>> differently. I don't recall which ones right at the moment. I will
>>>>> double
>>>>> check when I get home.
>>>>>
>>>>>
>>>> A 'delete' for every 'remove' may be practical for mem Graphs but for TDB
>>>> it would be a complete pain. remove in TDB does not materialise the
>>>> triples; it removes the NodeId triples/quads from the indexes but does
>>>> not
>>>> fetch the actual materialized node from the node table and that would be
>>>> needed to send the event with a triple in it [*]
>>>>
>>>>
>>> If "delete" and "remove" on the graph achieve the same result then I
>>> agree.
>>> I think there are several implementations that do not send delete for
>>> all
>>> triples deleted by a remove. But I wanted to check before I coded the
>>> contract check one way or the other.
>>>
>>> I think the contract is: when remove is called the graph may report
>>> deletion of all triples that were removed or it may report none but in
>>> either case it must report the remove <triple> operation.
>>>
>>
>>
>>
>>> Claude
>>>
>>>
>>> To do so would be very expensive - likely to slow the operation down at
>>>> scale by factors of x2 or maybe more.
>>>>
>>>> So if there is lack of clarity of contract, I suggest that delete's for
>>>> remove are optional or not done.
>>>>
>>>> (If there is already a contract, TDB will have to live with it).
>>>>
>>>> Andy
>>>>
>>>> [*] Weird delayed evaluation theoretically possible - query results do it
>>>> already - but in the current node design it's a major change - the node
>>>> type is not known from the NodeId (and for other reasons, possible a bad
>>>> idea but I was number-of-bits conscious).
>>>>
>>>>
>>>> Claude.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
Re: graph remove( node, node, node) side effects?
Posted by Claude Warren <cl...@xenei.com>.
I have no problem making changes. The problem is I don't know what the
proper action should be, hence all my questions as of late.
On Tue, Oct 8, 2013 at 9:31 AM, Andy Seaborne <an...@apache.org> wrote:
> On 07/10/13 22:38, Claude Warren wrote:
>
>> On Mon, Oct 7, 2013 at 10:11 PM, Andy Seaborne <an...@apache.org> wrote:
>>
>> On 07/10/13 09:10, Claude Warren wrote:
>>>
>>> When calling graph.remove( A , B, C )
>>>> should the graphListener be informed of delete( Triple<A, B, C> ) as
>>>> well
>>>> as the graph event ( remove A B C )? I am assuming that the answer is
>>>> yes
>>>> always.
>>>>
>>>>
>>> Don't know -- what does the code do currently?
>>>
>>> It varies depending upon the implementation.
>>>
>>
>>
>>>
>>> Functionally, what is the difference between remove( A, B, C ) and
>>>> delete
>>>> (Triple<A,B,C>)?
>>>>
>>>>
>>> Javadoc:
>>> [[
>>> remove(Node s, Node p, Node o)
>>> Remove all triples that match by find(s, p, o)
>>> ]]
>>>
>>> Graph.remove is a pattern (Node.ANYs allowed, and nulls),
>>> Graph.delete(Triple) affects only and exactly that triple, no pattern.
>>>
>>
>>
>> My reading of the java doc is that I can pass any triple so Graph.delete(
>> Triple.ANY ) will delete all triples from the grap (extreme example) but
>> that other patters would also be allowed. If patterns are not allowed I
>> think we should update the docs. If they are allowed it sounds like the
>> difference is the use of the triple or the 3 nodes.
>>
>
> Claude,
>
> You have commit access on the codebase so do go ahead and fix things that
> you find need fixing.
>
> Andy
>
>
> I managed to get the contract tests for the graph complete yesterday and
>>>
>>>> found that different implementations of graph seem to handle this
>>>> differently. I don't recall which ones right at the moment. I will
>>>> double
>>>> check when I get home.
>>>>
>>>>
>>> A 'delete' for every 'remove' may be practical for mem Graphs but for TDB
>>> it would be a complete pain. remove in TDB does not materialise the
>>> triples; it removes the NodeId triples/quads from the indexes but does
>>> not
>>> fetch the actual materialized node from the node table and that would be
>>> needed to send the event with a triple in it [*]
>>>
>>>
>> If "delete" and "remove" on the graph achieve the same result then I
>> agree.
>> I think there are several implementations that do not send delete for
>> all
>> triples deleted by a remove. But I wanted to check before I coded the
>> contract check one way or the other.
>>
>> I think the contract is: when remove is called the graph may report
>> deletion of all triples that were removed or it may report none but in
>> either case it must report the remove <triple> operation.
>>
>
>
>
>> Claude
>>
>>
>> To do so would be very expensive - likely to slow the operation down at
>>> scale by factors of x2 or maybe more.
>>>
>>> So if there is lack of clarity of contract, I suggest that delete's for
>>> remove are optional or not done.
>>>
>>> (If there is already a contract, TDB will have to live with it).
>>>
>>> Andy
>>>
>>> [*] Weird delayed evaluation theoretically possible - query results do it
>>> already - but in the current node design it's a major change - the node
>>> type is not known from the NodeId (and for other reasons, possible a bad
>>> idea but I was number-of-bits conscious).
>>>
>>>
>>> Claude.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
--
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: graph remove( node, node, node) side effects?
Posted by Andy Seaborne <an...@apache.org>.
On 07/10/13 22:38, Claude Warren wrote:
> On Mon, Oct 7, 2013 at 10:11 PM, Andy Seaborne <an...@apache.org> wrote:
>
>> On 07/10/13 09:10, Claude Warren wrote:
>>
>>> When calling graph.remove( A , B, C )
>>> should the graphListener be informed of delete( Triple<A, B, C> ) as well
>>> as the graph event ( remove A B C )? I am assuming that the answer is yes
>>> always.
>>>
>>
>> Don't know -- what does the code do currently?
>>
>> It varies depending upon the implementation.
>
>>
>>
>>> Functionally, what is the difference between remove( A, B, C ) and delete
>>> (Triple<A,B,C>)?
>>>
>>
>> Javadoc:
>> [[
>> remove(Node s, Node p, Node o)
>> Remove all triples that match by find(s, p, o)
>> ]]
>>
>> Graph.remove is a pattern (Node.ANYs allowed, and nulls),
>> Graph.delete(Triple) affects only and exactly that triple, no pattern.
>
>
> My reading of the java doc is that I can pass any triple so Graph.delete(
> Triple.ANY ) will delete all triples from the grap (extreme example) but
> that other patters would also be allowed. If patterns are not allowed I
> think we should update the docs. If they are allowed it sounds like the
> difference is the use of the triple or the 3 nodes.
Claude,
You have commit access on the codebase so do go ahead and fix things
that you find need fixing.
Andy
>> I managed to get the contract tests for the graph complete yesterday and
>>> found that different implementations of graph seem to handle this
>>> differently. I don't recall which ones right at the moment. I will
>>> double
>>> check when I get home.
>>>
>>
>> A 'delete' for every 'remove' may be practical for mem Graphs but for TDB
>> it would be a complete pain. remove in TDB does not materialise the
>> triples; it removes the NodeId triples/quads from the indexes but does not
>> fetch the actual materialized node from the node table and that would be
>> needed to send the event with a triple in it [*]
>>
>
> If "delete" and "remove" on the graph achieve the same result then I agree.
> I think there are several implementations that do not send delete for all
> triples deleted by a remove. But I wanted to check before I coded the
> contract check one way or the other.
>
> I think the contract is: when remove is called the graph may report
> deletion of all triples that were removed or it may report none but in
> either case it must report the remove <triple> operation.
>
> Claude
>
>
>> To do so would be very expensive - likely to slow the operation down at
>> scale by factors of x2 or maybe more.
>>
>> So if there is lack of clarity of contract, I suggest that delete's for
>> remove are optional or not done.
>>
>> (If there is already a contract, TDB will have to live with it).
>>
>> Andy
>>
>> [*] Weird delayed evaluation theoretically possible - query results do it
>> already - but in the current node design it's a major change - the node
>> type is not known from the NodeId (and for other reasons, possible a bad
>> idea but I was number-of-bits conscious).
>>
>>
>>> Claude.
>>>
>>>
>>>
>>>
>>>
>>
>
>
Re: graph remove( node, node, node) side effects?
Posted by Claude Warren <cl...@xenei.com>.
On Mon, Oct 7, 2013 at 10:11 PM, Andy Seaborne <an...@apache.org> wrote:
> On 07/10/13 09:10, Claude Warren wrote:
>
>> When calling graph.remove( A , B, C )
>> should the graphListener be informed of delete( Triple<A, B, C> ) as well
>> as the graph event ( remove A B C )? I am assuming that the answer is yes
>> always.
>>
>
> Don't know -- what does the code do currently?
>
> It varies depending upon the implementation.
>
>
>> Functionally, what is the difference between remove( A, B, C ) and delete
>> (Triple<A,B,C>)?
>>
>
> Javadoc:
> [[
> remove(Node s, Node p, Node o)
> Remove all triples that match by find(s, p, o)
> ]]
>
> Graph.remove is a pattern (Node.ANYs allowed, and nulls),
> Graph.delete(Triple) affects only and exactly that triple, no pattern.
My reading of the java doc is that I can pass any triple so Graph.delete(
Triple.ANY ) will delete all triples from the grap (extreme example) but
that other patters would also be allowed. If patterns are not allowed I
think we should update the docs. If they are allowed it sounds like the
difference is the use of the triple or the 3 nodes.
>
> I managed to get the contract tests for the graph complete yesterday and
>> found that different implementations of graph seem to handle this
>> differently. I don't recall which ones right at the moment. I will
>> double
>> check when I get home.
>>
>
> A 'delete' for every 'remove' may be practical for mem Graphs but for TDB
> it would be a complete pain. remove in TDB does not materialise the
> triples; it removes the NodeId triples/quads from the indexes but does not
> fetch the actual materialized node from the node table and that would be
> needed to send the event with a triple in it [*]
>
If "delete" and "remove" on the graph achieve the same result then I agree.
I think there are several implementations that do not send delete for all
triples deleted by a remove. But I wanted to check before I coded the
contract check one way or the other.
I think the contract is: when remove is called the graph may report
deletion of all triples that were removed or it may report none but in
either case it must report the remove <triple> operation.
Claude
> To do so would be very expensive - likely to slow the operation down at
> scale by factors of x2 or maybe more.
>
> So if there is lack of clarity of contract, I suggest that delete's for
> remove are optional or not done.
>
> (If there is already a contract, TDB will have to live with it).
>
> Andy
>
> [*] Weird delayed evaluation theoretically possible - query results do it
> already - but in the current node design it's a major change - the node
> type is not known from the NodeId (and for other reasons, possible a bad
> idea but I was number-of-bits conscious).
>
>
>> Claude.
>>
>>
>>
>>
>>
>
--
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: graph remove( node, node, node) side effects?
Posted by Andy Seaborne <an...@apache.org>.
On 07/10/13 09:10, Claude Warren wrote:
> When calling graph.remove( A , B, C )
> should the graphListener be informed of delete( Triple<A, B, C> ) as well
> as the graph event ( remove A B C )? I am assuming that the answer is yes
> always.
Don't know -- what does the code do currently?
>
> Functionally, what is the difference between remove( A, B, C ) and delete
> (Triple<A,B,C>)?
Javadoc:
[[
remove(Node s, Node p, Node o)
Remove all triples that match by find(s, p, o)
]]
Graph.remove is a pattern (Node.ANYs allowed, and nulls),
Graph.delete(Triple) affects only and exactly that triple, no pattern.
> I managed to get the contract tests for the graph complete yesterday and
> found that different implementations of graph seem to handle this
> differently. I don't recall which ones right at the moment. I will double
> check when I get home.
A 'delete' for every 'remove' may be practical for mem Graphs but for
TDB it would be a complete pain. remove in TDB does not materialise the
triples; it removes the NodeId triples/quads from the indexes but does
not fetch the actual materialized node from the node table and that
would be needed to send the event with a triple in it [*]
To do so would be very expensive - likely to slow the operation down at
scale by factors of x2 or maybe more.
So if there is lack of clarity of contract, I suggest that delete's for
remove are optional or not done.
(If there is already a contract, TDB will have to live with it).
Andy
[*] Weird delayed evaluation theoretically possible - query results do
it already - but in the current node design it's a major change - the
node type is not known from the NodeId (and for other reasons, possible
a bad idea but I was number-of-bits conscious).
>
> Claude.
>
>
>
>