Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0.0
    • Fix Version/s: 2.0.0
    • Component/s: Database Core
    • Labels:
      None
    • Skill Level:
      Committers Level (Medium to Hard)

      Description

      We should rename the "revisions" to "lock" or "token" or some other suitably opaque term so we stop getting people asking questions about treating them as revisions.

        Activity

        Hide
        Paul Joseph Davis added a comment -

        @Alexander

        Yes, all the other bits would need to be renamed to match the new name as well. I honestly don't care what it's renamed to as long as it doesn't have a revision connotation.

        @Dirkjan

        If by exceedingly limited you mean removes an entire class of misunderstanding in the community, then yes. But I do think this is something we should at least be considering. Also, I'm assuming that 2.0 will have other similarly large breaks in API so I don't see this as much of an issue since its mostly just a renaming of a concept (with no current plans at actually changing behavior).

        Show
        Paul Joseph Davis added a comment - @Alexander Yes, all the other bits would need to be renamed to match the new name as well. I honestly don't care what it's renamed to as long as it doesn't have a revision connotation. @Dirkjan If by exceedingly limited you mean removes an entire class of misunderstanding in the community, then yes. But I do think this is something we should at least be considering. Also, I'm assuming that 2.0 will have other similarly large breaks in API so I don't see this as much of an issue since its mostly just a renaming of a concept (with no current plans at actually changing behavior).
        Hide
        Dirkjan Ochtman added a comment -

        This seems like exceedingly limited benefit for a big break in compatibility. I'd suggest the solution should be better docs, instead.

        Show
        Dirkjan Ochtman added a comment - This seems like exceedingly limited benefit for a big break in compatibility. I'd suggest the solution should be better docs, instead.
        Hide
        Alexander Shorin added a comment -

        Would `_state` name be more convenient? May be I'm wrong, but I'd like to count `_rev` as document state id, because it's better describes functional of this field: last document state, conflict document states etc.
        Also, there are `_revisions` and `_attachments/revpos` fields that should be noticed too as well as `db/_rev_count` resource and `rev`, `rev_info`, `open_revs` document resource parameters. Have I missed something?

        Show
        Alexander Shorin added a comment - Would `_state` name be more convenient? May be I'm wrong, but I'd like to count `_rev` as document state id, because it's better describes functional of this field: last document state, conflict document states etc. Also, there are `_revisions` and `_attachments/revpos` fields that should be noticed too as well as `db/_rev_count` resource and `rev`, `rev_info`, `open_revs` document resource parameters. Have I missed something?

          People

          • Assignee:
            Unassigned
            Reporter:
            Paul Joseph Davis
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development