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. > > 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
