github.com/cockroachdb/cockroach@v20.2.0-alpha.1+incompatible/docs/RFCS/20150729_range_replica_naming.md (about)

     1  - Feature Name: range_replica_naming
     2  - Status: completed
     3  - Start Date: 2015-07-29
     4  - RFC PR: [#1864](https://github.com/cockroachdb/cockroach/pull/1864)
     5  - Cockroach Issue:
     6  
     7  # Summary
     8  
     9  Consistently use the word **range** to refer to a portion of the global
    10  sorted map (i.e. an entire raft consensus group, and **replica** to
    11  refer to a single copy of the range's data.
    12  
    13  # Motivation
    14  
    15  We currently use the word "range" informally to refer to both the
    16  consensus group and the data owned by one member of the group, while
    17  in code the `storage.Range` type refers to the latter. This was a
    18  deliberate at the time because (at least in code) the latter is more
    19  common than the former. However, resolving certain issues related to
    20  replication and splits requires us to be precise about the difference,
    21  so I propose separating the two usages to improve clarity.
    22  
    23  # Detailed design
    24  
    25  Rename the type `storage.Range` to `storage.Replica`, and `range_*.go`
    26  to `replica_*.go`. Rename `RaftID` to `RangeID` (the name `RaftID` was
    27  chosen to avoid the ambiguity inherent in our old use of "range"). A
    28  new `Range` type may be created to house pieces of `Replica` that do
    29  in fact belong at the level of the range (for example, the
    30  `AdminSplit`, `AdminMerge`, and `ChangeReplicas` methods)
    31  
    32  # Drawbacks
    33  
    34  This reverses a previously-made decision and moves/renames a lot of code.
    35  
    36  # Alternatives
    37  
    38  Keep `Range` for a single replica and use `Raft` or `Group` when
    39  naming things that relate to the whole group.
    40  
    41  # Unresolved questions