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

Default namespace not selected in Workbench

    Details

    • Type: Bug
    • Status: Done
    • Priority: Highest
    • Resolution: Done
    • Affects Version/s: BIGDATA_RELEASE_1_5_0
    • Fix Version/s: BLAZEGRAPH_RELEASE_1_5_2
    • Component/s: Workbench
    • Labels:
      None

      Description

      When starting blazegraph (with default configuration) and opening the workbench, the default namespace is not pre-selected but must be set manually.

      This is actually a regression, the default namespace kb used to be selected by default in previous versions.

        Activity

        Hide
        micheldumontier micheldumontier added a comment -

        how does one set the namespace using the jar distro?

        Show
        micheldumontier micheldumontier added a comment - how does one set the namespace using the jar distro?
        Hide
        michaelschmidt michaelschmidt added a comment -

        For the Nano SPARQL server, the namespace is passed as a param, e.g.

        java $JAVA_OPTS -server -cp bigdata.jar com.bigdata.rdf.sail.webapp.NanoSparqlServer $PORT $NAMESPACE $CONFIG_FILE
        

        (see http://wiki.bigdata.com/wiki/index.php/NanoSparqlServer). This sets the namespace correctly, i.e. queries against the default SPARQL endpoint are issued against the namespace set when starting the server.

        EDIT: the problem only affects the default namespace and only pops up when starting the server as a webapp.

        Show
        michaelschmidt michaelschmidt added a comment - For the Nano SPARQL server, the namespace is passed as a param, e.g. java $JAVA_OPTS -server -cp bigdata.jar com.bigdata.rdf.sail.webapp.NanoSparqlServer $PORT $NAMESPACE $CONFIG_FILE (see http://wiki.bigdata.com/wiki/index.php/NanoSparqlServer ). This sets the namespace correctly, i.e. queries against the default SPARQL endpoint are issued against the namespace set when starting the server. EDIT: the problem only affects the default namespace and only pops up when starting the server as a webapp.
        Hide
        bryanthompson bryanthompson added a comment -

        This might be because the KB is not created at the time that the javascript client is initialized. I believe that the client queries the server and if there is nothing existing on the server at that time, it does not go back to the server unless you refresh the namespaces page. But this is only a hypothesis. I have not tried to track this down.

        Show
        bryanthompson bryanthompson added a comment - This might be because the KB is not created at the time that the javascript client is initialized. I believe that the client queries the server and if there is nothing existing on the server at that time, it does not go back to the server unless you refresh the namespaces page. But this is only a hypothesis. I have not tried to track this down.
        Hide
        beebs Brad Bebee added a comment -

        This was introduced by design. The issue in question was what type of namespace to create by default, i.e. a Blueprints compatible one or not. If we can resolve that question, I don't see an issue with the default creation.

        Show
        beebs Brad Bebee added a comment - This was introduced by design. The issue in question was what type of namespace to create by default, i.e. a Blueprints compatible one or not. If we can resolve that question, I don't see an issue with the default creation.
        Hide
        michaelschmidt michaelschmidt added a comment -

        @Brad: could you provide some pointers to the ticket/checkin where this behavior was changed? Shouldn't the preselection of the namespace in the client be "independent" of any creation issues? Whenever the client is used and there's only one namespace detected, we could pick that one. In addition, we might have rules for selecting the default one if none is selected and there's a default namespace (called "kb"). Makes sense?

        Show
        michaelschmidt michaelschmidt added a comment - @Brad: could you provide some pointers to the ticket/checkin where this behavior was changed? Shouldn't the preselection of the namespace in the client be "independent" of any creation issues? Whenever the client is used and there's only one namespace detected, we could pick that one. In addition, we might have rules for selecting the default one if none is selected and there's a default namespace (called "kb"). Makes sense?
        Hide
        beebs Brad Bebee added a comment -

        The previous behavior was to create the "default" kb namespace when the Servlet started (this is context parameter in the web.xml I believe) and select that name space. The gist of the discussion was what the default values should be for those properties. At the time, the decision was made to change the workbench to not create a KB and not select one be default.

        There are clearly downsides. I think your logic would make sense and re-enable creating the default namespace. I have created a sub-task to provide a reasonable error / Exception handling to cover the case where a property graph client tries to connect to a namespace that is not configured for property graphs.

        Show
        beebs Brad Bebee added a comment - The previous behavior was to create the "default" kb namespace when the Servlet started (this is context parameter in the web.xml I believe) and select that name space. The gist of the discussion was what the default values should be for those properties. At the time, the decision was made to change the workbench to not create a KB and not select one be default. There are clearly downsides. I think your logic would make sense and re-enable creating the default namespace. I have created a sub-task to provide a reasonable error / Exception handling to cover the case where a property graph client tries to connect to a namespace that is not configured for property graphs.
        Hide
        michaelschmidt michaelschmidt added a comment -

        OK, for now it would be perfectly fine for us when selecting the workbench default namespace just in case there's only one namespace (which covers most of the cases anyway, I'd guess). Could you have a look at my proposed fix at https://github.com/SYSTAP/bigdata/compare/blzg-1177. We could then still discuss this issue in more detail later.

        Show
        michaelschmidt michaelschmidt added a comment - OK, for now it would be perfectly fine for us when selecting the workbench default namespace just in case there's only one namespace (which covers most of the cases anyway, I'd guess). Could you have a look at my proposed fix at https://github.com/SYSTAP/bigdata/compare/blzg-1177 . We could then still discuss this issue in more detail later.
        Hide
        beebs Brad Bebee added a comment -

        I merged it down.

        Show
        beebs Brad Bebee added a comment - I merged it down.
        Hide
        beebs Brad Bebee added a comment -

        Created a PR and merged it down.

        Show
        beebs Brad Bebee added a comment - Created a PR and merged it down.
        Hide
        bryanthompson bryanthompson added a comment -

        Brad Bebee Can this be closed against some fix version?

        Show
        bryanthompson bryanthompson added a comment - Brad Bebee Can this be closed against some fix version?
        Hide
        beebs Brad Bebee added a comment -

        This one is closed. I'll convert the uncompleted subtask into a separate ticket.

        Show
        beebs Brad Bebee added a comment - This one is closed. I'll convert the uncompleted subtask into a separate ticket.

          People

          • Assignee:
            michaelschmidt michaelschmidt
            Reporter:
            michaelschmidt michaelschmidt
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: