On 07/10/13 22:38, Claude Warren wrote:
On Mon, Oct 7, 2013 at 10:11 PM, Andy Seaborne <[email protected]> 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.
