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.
