Menu
▾
▴
Re: [Bigdata-developers] Breakdown of mutation count statistic or way of aborting an update
|
From: Bryan T. <br...@sy...> - 2015-02-10 23:33:17
|
Thinking about it. In general, this sort of mechanism should be Ok. I certainly agree with improving the UPDATE response formatting options. The concept of an ABORT IF seems valid. Basically, database side validation. We have been discussing some other validation mechanisms. Michael (Cc) has done some work in this area and developed a comparison of some different approaches. In general, an ASK is a very heavy option. It sounds relevant in your case. Many consistency check options can be much lighter which is more where my thoughts have been - triggers and enabling object oriented extensions of the database (in terms of schema validation and constraints, object oriented data interchange and query, and server-side object behaviors). ---- Bryan Thompson Chief Scientist & Founder SYSTAP, LLC 4501 Tower Road Greensboro, NC 27410 br...@sy... http://bigdata.com http://mapgraph.io CONFIDENTIALITY NOTICE: This email and its contents and attachments are for the sole use of the intended recipient(s) and are confidential or proprietary to SYSTAP. Any unauthorized review, use, disclosure, dissemination or copying of this email or its contents or attachments is prohibited. If you have received this communication in error, please notify the sender by reply email and permanently delete all copies of the email and its contents and attachments. On Tue, Feb 10, 2015 at 12:53 PM, Jeremy J Carroll <jj...@sy...> wrote: > This may be an enhancement suggestion to > com.bigdata.rdf.sail.webapp.BigdataRDFContext.SparqlUpdateResponseWriter.updateEvent(SPARQLUpdateEvent) > > What I really want to do is: > > 1) make an update using a DELETE/INSERT SPARQL update query > 2) make several ASK queries > 3) abort 1 if the result of any of the queries in 2 was false > 4) know which of the queries in 2 was false > > I am generally expecting the ASK queries to all return true, and can live > with inefficiencies in step 4. > I am using the NanoSPARQLServer, and want the whole operation 1 - 4 to be > safe to use concurrently. > > A possible fairly direct approach of meeting my use case would be to provide > extensions to SPARQL update with an > ABORT IF ASK …. > (which is the negation of 3, …) > and providing more control over the SparqlUpdateResponseWriter > > > Using the NSS, posting a multipart SPARQL update e.g.: > > ===== > INSERT { > GRAPH <http://foo.bar/> { > <http://foo.bar/> <http://foo.bar/> 3 . > } > } > WHERE {} ; > > DELETE { > GRAPH <http://foo.bar/> > { ?s ?p ?o } > } > WHERE { > GRAPH <http://foo.bar/> > { ?s ?p ?o } > FILTER ( true ) > } > ===== > > in which the second operation undoes the first. > What I currently get back is (a variation of): > > === > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" > "http://www.w3.org/TR/html4/loose.dtd"><html><head><meta > http-equiv="Content-Type" > content="text/html;charset=UTF-8"><title>bigdata®</title >></head >><body><pre>DeleteInsert > INSERT > > QUADS { > QUADS { > > StatementPatternNode(ConstantNode(TermId(1U)[http://foo.bar/]), > ConstantNode(TermId(1U)[http://foo.bar/]), > ConstantNode(XSDInteger(3)), > ConstantNode(TermId(1U)[http://foo.bar/])) > [scope=NAMED_CONTEXTS] > } > } > WHERE > JoinGroupNode { > } > </pre >><p>totalElapsed=2ms, elapsed=2ms</p >><hr><pre>DeleteInsert > DELETE > > QUADS { > QUADS { > StatementPatternNode(VarNode(s), VarNode(p), VarNode(o), VarNode(g)) > [scope=NAMED_CONTEXTS] > } > } > WHERE > JoinGroupNode { > JoinGroupNode [context=VarNode(g)] { > StatementPatternNode(VarNode(s), VarNode(p), VarNode(o), VarNode(g)) > [scope=NAMED_CONTEXTS] > } > } > </pre >><p>totalElapsed=58ms, elapsed=52ms</p >><hr><p>COMMIT: totalElapsed=70ms, commitTime=1423585942631, >> mutationCount=2</p >></body >></html >> > === > Looking at the code, it would be fairly easy to also include the > mutationCount after each operation. > > I could then structure my code as, > > DELETE INSERT ; > > (reversed) DELETE INSERT IF ASK 1 ; > (reversed) DELETE INSERT IF ASK 2 ; > (reversed) DELETE INSERT IF ASK 3 ; > > and then the result would tell me, by analysis of the mutation counts, if > any of the ASK conditions held true. > > It would also be helpful if I could switch off the bulk of the uninteresting > echo in > body.node("pre").text(thisOp.toString())// > .close(); > in > > com.bigdata.rdf.sail.webapp.BigdataRDFContext.SparqlUpdateResponseWriter.updateEvent(SPARQLUpdateEvent) > My operations are often fairly large, and the cost of this data that I never > examine is non-trivial > > My best outcome, would be: > improved control over the SparqlUpdateResponseWriter > and an ABORT operation > so that my update becomes > > DELETE INSERT ; > ABORT IF ASK 1 ; > ABORT IF ASK 2 ; > ABORT IF ASK 3 > > and the analysis of the return result is to find out which of the ABORTs > fired (if any) > > Jeremy > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Bigdata-developers mailing list > Big...@li... > https://lists.sourceforge.net/lists/listinfo/bigdata-developers > |
