Uploaded image for project: 'Blazegraph (by SYSTAP)'
  1. Blazegraph (by SYSTAP)
  2. BLZG-824

Provide an XHTML response for SPARQL UPDATE requests

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Open
    • Priority: Medium
    • Resolution: Unresolved
    • Affects Version/s: BIGDATA_RELEASE_1_2_3
    • Fix Version/s: None
    • Component/s: NanoSparqlServer
    • Labels:
      None

      Description

      Per [1] and the developer's list. All other mutation methods of the REST API provide access to a mutation count in a simple XML document. SPARQL UPDATE can be a complex sequence of operations, including multiple LOADs. Also, it can be useful to observe the incremental response of those LOADs. The current document is HTML. It does have a mutation counter (as of 08/03/2013) but is not XML and does not share any characteristics with the XML response for the REST API INSERT, UPDATE or DELETE methods.

      The current XML response for the other mutation methods is simply:

      <data modified="5" milliseconds="112"/>
      

      The current SPARQL UPDATE 1.1 response is quite different.

                  XMLBuilder.Node current = doc.root("html");
                  {
                      current = current.node("head");
                      current.node("meta").attr("http-equiv", "Content-Type")
                              .attr("content", "text/html;charset=" + charset.name())
                              .close();
                      current.node("title").textNoEncode("bigdata&BLZG-347;").close();
                      current = current.close();// close the head.
                  }
      ...
                  // open the body
                  current = current.node("body");
      ...
                  // incremental reporting for LOAD operations.
                              body.node("br")
                                      .text("totalElapsed=" + totalElapsedMillis
                                              + "ms, elapsed=" + elapsedMillis
                                              + "ms, parsed=" + parsed + ", tps="
                                              + tmp.triplesPerSecond() + ", done="
                                              + tmp.isDone()).close();
      ...
                  // reporting on ABORT of request
                          body.node("p").text("ABORT").close()//
                          .node("pre").text(e.getUpdate().toString()).close()//
                          .node("pre").text(w.toString()).close()//
                          .node("p").text("totalElapsed=" + totalElapsedMillis
                                  + "ms, elapsed=" + elapsedMillis + "ms")
                          .close();
      
                          // horizontal line after each operation.
                          body.node("hr").close();
      ...
                  // reporting at end of each UPDATE operation in a request (there can be more than one)
                              body.node("pre")
                                      .text(e.getUpdate().toString())
                                      .close()
                                      //
                                      .node("p")
                                      .text("totalElapsed=" + totalElapsedMillis
                                              + "ms, elapsed=" + elapsedMillis + "ms")//
                                      .close();
                         }
                          
                          // horizontal line after each operation.
                          body.node("hr").close();
      ...
                  // reporting at commit (one per update request)
                  body.node("p")
                          .text("COMMIT: totalElapsed=" + totalElapsedMillis
                                  + "ms, commitTime=" + commitTime
                                  + ", mutationCount=" + mutationCount.get())//
                          .close();
      

      Before acting on this ticket, we need to reconcile these models to have a common minimum document type.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              igorkim igorkim
              Reporter:
              bryanthompson bryanthompson
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated: