Details

      Description

      Create a SERVICE that permits developers to register and execute stored queries.

      A stored query could be any of:

      1. A simple SPARQL query;
      2. Java procedural code that can execute multiple queries with arbitrary application logic.
      3. A groovy script.

      See the wiki page for more detail: http://wiki.bigdata.com/wiki/index.php/StoredQuery

      Here is an example stored query SERVICE invocation. The SERVICE URI is whatever URI you used when you registered your stored query.

      PREFIX : <http://example.org/book/>
      
      SELECT ?book ?title ?price
      {
         SERVICE <http://www.bigdata.com/rdf/stored-query#test_stored_query_002> {
             bd:serviceParam :book :book1
         }
      } 
      

      The result of a stored query are a solution multi-set. The top-level query may use that multi-set to project out a SPARQL result set, CONSTRUCT triples or quads, etc.

      The parameters passed into the stored query are declared by:

             bd:serviceParam :book :book1
      

      This produces a set containing the distinct predicates (which are the keys) to the LIST of values for each key (the Objects). This is a general purpose mechanism for passing in arguments to the stored query.

      The main implementation class is StoredQueryService. This can be used for arbitrary application logic.

      There is also a SimpleStoredQueryService that runs a parameterized SPARQL query.

      ---

      Note: For HA, the application will need to register the stored query against each HAJournalServer instance. This is easy enough if it is done at compile time by hooking the BigdataRDFServletContextListener using ConfigParams.SERVLET_CONTEXT_LISTENER_CLASS

          /**
           * A class that extends {@link BigdataRDFServletContextListener}. This
           * offers applications a means to hook the {@link ServletContextListener}
           * methods.
           * <p>
           * Note:
           * 
           * @see BigdataRDFServletContextListener#contextInitialized(ServletContextEvent)
           * @see BigdataRDFServletContextListener#contextDestroyed(ServletContextEvent)
           * @see #DEFAULT_SERVLET_CONTEXT_LISTENER_CLASS
           * 
           * @see <a href="https://sourceforge.net/apps/trac/bigdata/ticket/667" >
           *      Provide NanoSparqlServer initialization hook </a>
           */
          String SERVLET_CONTEXT_LISTENER_CLASS = "servletContextListenerClass";
      
          String DEFAULT_SERVLET_CONTEXT_LISTENER_CLASS = BigdataRDFServletContextListener.class
                  .getName();
      

      See http://wiki.bigdata.com/wiki/index.php/StoredQuery (Wiki page for stored queries)

        Activity

        Hide
        bryanthompson bryanthompson added a comment -

        Mike wrote:

        S is a magic predicate, doesn't matter what it is.

        service bsq:queryName {
            magic:queryParam magic:"key1" "val1" .  
            magic:queryParam magic:"key2" "val2" .
            ...
        }
        

        Create a base service class to extend. Parse the magic:queryParams for the base class. Turn the local name of the predicate into the key and the O is the value. Provide these key-value pairs as a map as input to the concrete stored query when invoked from a SERVICE call. Make them supply the URI for their stored query (so each stored query is its own service, or perhaps they are all URIs in a bigdata specific namespace).

        We probably want to force the service to list its input variables and its definitely and maybe bound output variables as part of the API. That will make it possible for us do do static analysis on the stored query, at least in terms of the variable bindings.

        Show
        bryanthompson bryanthompson added a comment - Mike wrote: S is a magic predicate, doesn't matter what it is. service bsq:queryName { magic:queryParam magic:"key1" "val1" . magic:queryParam magic:"key2" "val2" . ... } Create a base service class to extend. Parse the magic:queryParams for the base class. Turn the local name of the predicate into the key and the O is the value. Provide these key-value pairs as a map as input to the concrete stored query when invoked from a SERVICE call. Make them supply the URI for their stored query (so each stored query is its own service, or perhaps they are all URIs in a bigdata specific namespace). We probably want to force the service to list its input variables and its definitely and maybe bound output variables as part of the API. That will make it possible for us do do static analysis on the stored query, at least in terms of the variable bindings.
        Hide
        bryanthompson bryanthompson added a comment -

        Check-point on the stored-query service. A simple service has been implemented that can execute a single SPARQL query. I am going to refactor to allow stored queries to do complex application processing including the submission of multiple queries while holding a set of locks.

        I moved the core code for the group commit interfaces used by the REST API into a different package and am reusing them for the stored query service.

        I pulled out the ServiceParams helper class so it can be used with services that use the openrdf data structures (BindingSet[]) versus the bigdata data structures (IBindingSet[]).

        Committed revision r8532.

        Show
        bryanthompson bryanthompson added a comment - Check-point on the stored-query service. A simple service has been implemented that can execute a single SPARQL query. I am going to refactor to allow stored queries to do complex application processing including the submission of multiple queries while holding a set of locks. I moved the core code for the group commit interfaces used by the REST API into a different package and am reusing them for the stored query service. I pulled out the ServiceParams helper class so it can be used with services that use the openrdf data structures (BindingSet[]) versus the bigdata data structures (IBindingSet[]). Committed revision r8532.
        Hide
        bryanthompson bryanthompson added a comment -

        Javadoc around bd:serviceParam and ServiceParams.

        Second test case for the stored query service.

        Committed revision r8533.

        Show
        bryanthompson bryanthompson added a comment - Javadoc around bd:serviceParam and ServiceParams. Second test case for the stored query service. Committed revision r8533.
        Hide
        bryanthompson bryanthompson added a comment -

        Next steps:

        1. Generalize the stored query service to allow complex application code, not just the execution of a single SPARQL query.
        2. Bundle groovy and support execution of groovy scripts (if this is not too difficult).
        Show
        bryanthompson bryanthompson added a comment - Next steps: Generalize the stored query service to allow complex application code, not just the execution of a single SPARQL query. Bundle groovy and support execution of groovy scripts (if this is not too difficult).
        Hide
        bryanthompson bryanthompson added a comment -

        Generalized the stored query service to allow arbitrary task logic while holding a connection that reads on the KB.

        Committed revision r8534.

        Show
        bryanthompson bryanthompson added a comment - Generalized the stored query service to allow arbitrary task logic while holding a connection that reads on the KB. Committed revision r8534.
        Hide
        bryanthompson bryanthompson added a comment -

        Added a generalized case for arbitrary application logic for stored queries.

        There is also a special case for a parameterized SPARQL query.

        Committed revision r8535.

        Show
        bryanthompson bryanthompson added a comment - Added a generalized case for arbitrary application logic for stored queries. There is also a special case for a parameterized SPARQL query. Committed revision r8535.

          People

          • Assignee:
            bryanthompson bryanthompson
            Reporter:
            bryanthompson bryanthompson
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: