Details

    • Type: Sub-task Sub-task
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.6.0
    • Component/s: None
    • Labels:
      None

      Description

      The name of the default namespace currently lives in org.apache.accumulo.client.impl.Namespaces which is not part of the public api. We should make this variable part of the public API to make it easier for users to interact with namespaces.

        Activity

        Hide
        Christopher Tubbs added a comment -

        In what way do you propose users interact with this value? The way it is currently implemented is similar to java classes in the default package. That is, the fully qualified table names for tables in the default namespace have no namespace prefix. Namespaces are not really first class citizens, like tables. So, can you clarify how you think this should change?

        Show
        Christopher Tubbs added a comment - In what way do you propose users interact with this value? The way it is currently implemented is similar to java classes in the default package. That is, the fully qualified table names for tables in the default namespace have no namespace prefix. Namespaces are not really first class citizens, like tables. So, can you clarify how you think this should change?
        Hide
        John Vines added a comment -

        It should exist in some sort of constants file which is part of the client api (i.e. guaranteed not to change). It is necessary for namespace interactions.

        Show
        John Vines added a comment - It should exist in some sort of constants file which is part of the client api (i.e. guaranteed not to change). It is necessary for namespace interactions.
        Hide
        ASF subversion and git services added a comment -

        Commit 26c51db4d77bbba2d9ce50e1d6d0efc718618e50 in branch refs/heads/1.6.0-SNAPSHOT from John Vines
        [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=26c51db ]

        ACCUMULO-2114 Starting a Constants reference for clients

        Show
        ASF subversion and git services added a comment - Commit 26c51db4d77bbba2d9ce50e1d6d0efc718618e50 in branch refs/heads/1.6.0-SNAPSHOT from John Vines [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=26c51db ] ACCUMULO-2114 Starting a Constants reference for clients
        Hide
        Christopher Tubbs added a comment -

        If you don't mind, I'd like to reopen this issue and move this from a Constants file to a method that returns in namespace operations, as I think that's a better implementation.

        Moving it to a method instead of a constant also enables us to optionally improve the client code in the future, so that one can set the default namespace with which to qualify tables when one instantiates a connector (similar to setting a default database when connecting to a SQL database with which to qualify tables in SQL statements).

        Show
        Christopher Tubbs added a comment - If you don't mind, I'd like to reopen this issue and move this from a Constants file to a method that returns in namespace operations, as I think that's a better implementation. Moving it to a method instead of a constant also enables us to optionally improve the client code in the future, so that one can set the default namespace with which to qualify tables when one instantiates a connector (similar to setting a default database when connecting to a SQL database with which to qualify tables in SQL statements).
        Hide
        John Vines added a comment -

        First idea sounds good to me. But I don't really see how it helps with the latter without interfering with a way to get the literal default namespace name.

        Show
        John Vines added a comment - First idea sounds good to me. But I don't really see how it helps with the latter without interfering with a way to get the literal default namespace name.
        Hide
        Christopher Tubbs added a comment -

        Well, I was thinking that the "default" namespace could be the results of getConnector().namespaceOps().getDefaultNamespace(), and the connector-specific default namespace would be the results of getConnector(namespace).namespaceOps().getDefaultNamespace(). But, I can see how this could be non-intuitive for users to understand the answer to the question: "What is the default default namespace?". Alternatively, we could add a separate namespaceOps().getCurrentNamespace() or something. The merits of that can be debated later if we decide to pursue that feature.

        Other reasons for moving it to namespaceOps():
        1. Constants are harder to find if separated into a separate file, because users don't know to go looking there if they're working with a separate class.
        2. Constants files tend to get bloated, which diminishes their value for consumers (although they still have value for refactoring).
        3. Encouraging client use of constants, with compile-time binding, means that compiled client code could break if we change the value of the constant.

        Show
        Christopher Tubbs added a comment - Well, I was thinking that the "default" namespace could be the results of getConnector().namespaceOps().getDefaultNamespace(), and the connector-specific default namespace would be the results of getConnector(namespace).namespaceOps().getDefaultNamespace(). But, I can see how this could be non-intuitive for users to understand the answer to the question: "What is the default default namespace?". Alternatively, we could add a separate namespaceOps().getCurrentNamespace() or something. The merits of that can be debated later if we decide to pursue that feature. Other reasons for moving it to namespaceOps(): 1. Constants are harder to find if separated into a separate file, because users don't know to go looking there if they're working with a separate class. 2. Constants files tend to get bloated, which diminishes their value for consumers (although they still have value for refactoring). 3. Encouraging client use of constants, with compile-time binding, means that compiled client code could break if we change the value of the constant.
        Hide
        ASF subversion and git services added a comment -

        Commit 7f789ecbdcb902f9a14ddb2192ffa5a42bb2787b in branch refs/heads/1.6.0-SNAPSHOT from Christopher Tubbs
        [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=7f789ec ]

        ACCUMULO-2114 Move built-in namespace names to a method

        Show
        ASF subversion and git services added a comment - Commit 7f789ecbdcb902f9a14ddb2192ffa5a42bb2787b in branch refs/heads/1.6.0-SNAPSHOT from Christopher Tubbs [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=7f789ec ] ACCUMULO-2114 Move built-in namespace names to a method
        Hide
        ASF subversion and git services added a comment -

        Commit 7f789ecbdcb902f9a14ddb2192ffa5a42bb2787b in branch refs/heads/master from Christopher Tubbs
        [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=7f789ec ]

        ACCUMULO-2114 Move built-in namespace names to a method

        Show
        ASF subversion and git services added a comment - Commit 7f789ecbdcb902f9a14ddb2192ffa5a42bb2787b in branch refs/heads/master from Christopher Tubbs [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=7f789ec ] ACCUMULO-2114 Move built-in namespace names to a method

          People

          • Assignee:
            Christopher Tubbs
            Reporter:
            John Vines
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development