Accumulo
  1. Accumulo
  2. ACCUMULO-2318

Renaming table don't require namespace

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.6.0
    • Component/s: client
    • Labels:
      None

      Description

      If you rename a table, the old table name must be fully qualified. But the destination table does not require the namespace prefix. First of all, this doesn't seem intuitive. Secondly, it will makes things monumentally difficult should we support renaming across namespaces.

        Issue Links

          Activity

          Hide
          ASF subversion and git services added a comment -

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

          ACCUMULO-2318 making rename's second argument require a namespace

          Show
          ASF subversion and git services added a comment - Commit 17324b9d00c30b2e1e31d9dfe5aaae369e832873 in branch refs/heads/1.6.0-SNAPSHOT from John Vines [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=17324b9 ] ACCUMULO-2318 making rename's second argument require a namespace
          Hide
          ASF subversion and git services added a comment -

          Commit 17324b9d00c30b2e1e31d9dfe5aaae369e832873 in branch refs/heads/master from John Vines
          [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=17324b9 ]

          ACCUMULO-2318 making rename's second argument require a namespace

          Show
          ASF subversion and git services added a comment - Commit 17324b9d00c30b2e1e31d9dfe5aaae369e832873 in branch refs/heads/master from John Vines [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=17324b9 ] ACCUMULO-2318 making rename's second argument require a namespace
          Hide
          Christopher Tubbs added a comment -

          The principle for the previous behavior, prior to this ticket, was, by analogy that "Rename Christopher Tubbs to Michael" was intuitive enough, and that one shouldn't have to say "Rename Christopher Tubbs to Michael Tubbs". Likewise, the first parameter could be fully-qualified, because it needed enough information to identify the table to change, and the second parameter was simply the new name to give the identified table (not a new location/namespace... simply a new name).

          I feel it's non-intuitive that a rename doesn't just update the name of the table, but might also move it. By expecting unqualified names, it's clear that this behavior is not possible, but we also allowed fully-qualified names, as long as it was referring to the same namespace, so users weren't surprised if they always used fully-qualified names.

          So, I'm not convinced this was any more intuitive than the documented behavior, but I'm not strongly tied to either one, as far as intuitive-ness. However, it was made quite clear in the javadoc how it was expected to work, and the previous implementation followed the documented behavior. It now no longer does. If this change is acceptable, then it needs a corresponding javadoc update.

          Show
          Christopher Tubbs added a comment - The principle for the previous behavior, prior to this ticket, was, by analogy that "Rename Christopher Tubbs to Michael" was intuitive enough, and that one shouldn't have to say "Rename Christopher Tubbs to Michael Tubbs". Likewise, the first parameter could be fully-qualified, because it needed enough information to identify the table to change, and the second parameter was simply the new name to give the identified table (not a new location/namespace... simply a new name). I feel it's non-intuitive that a rename doesn't just update the name of the table, but might also move it. By expecting unqualified names, it's clear that this behavior is not possible, but we also allowed fully-qualified names, as long as it was referring to the same namespace, so users weren't surprised if they always used fully-qualified names. So, I'm not convinced this was any more intuitive than the documented behavior, but I'm not strongly tied to either one, as far as intuitive-ness. However, it was made quite clear in the javadoc how it was expected to work, and the previous implementation followed the documented behavior. It now no longer does. If this change is acceptable, then it needs a corresponding javadoc update.
          Hide
          Christopher Tubbs added a comment -

          Also, a test should be added to NamespacesIT that explicitly tests that it will not work if unqualified.

          Show
          Christopher Tubbs added a comment - Also, a test should be added to NamespacesIT that explicitly tests that it will not work if unqualified.
          Hide
          John Vines added a comment -

          Javadocs need to be updated

          Show
          John Vines added a comment - Javadocs need to be updated
          Hide
          Keith Turner added a comment -

          John Vines are you planning on updating the javadocs?

          Show
          Keith Turner added a comment - John Vines are you planning on updating the javadocs?
          Hide
          John Vines added a comment -

          Yeah, I'll be getting to it next week

          Show
          John Vines added a comment - Yeah, I'll be getting to it next week
          Show
          Christopher Tubbs added a comment - Commit which fixed this: https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=commitdiff;h=4e499f35

            People

            • Assignee:
              John Vines
              Reporter:
              John Vines
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development