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 <[email protected]> wrote: > 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. >>>> >>>> >>>> >>>> >>>> >>>> >>> >> >> > -- I like: Like Like - The likeliest place on the web<http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
