CouchDB
  1. CouchDB
  2. COUCHDB-549

include_docs=true doesn't honour conflicts=true

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 0.11
    • Fix Version/s: 1.0.3, 1.1, 1.2
    • Component/s: HTTP Interface
    • Labels:
      None
    • Skill Level:
      Regular Contributors Level (Easy to Medium)

      Description

      When you read a view and use the option 'include_docs=true' to get the source document in each result row, the option 'conflicts=true' is not honoured. You do not see a _conflicts member in the document, even if it is in a conflicting state.

      This feature request could be expanded in a couple of directions:

      1. Make include_docs=true honour all options which a straightforward GET would honour - e.g. revs, revs_info, open_revs. Maybe this would be straightforward if they shared the same code path and options processing.

      2. It has been suggested that 'conflicts=true' could be the default anyway. That is, whenever you retrieve a document, you get a _conflicts member if it is in a conflicting state, without having to ask for it. This would be unlikely to break things, but would make it less likely that conflicts would go unnoticed, and it would simplify the API a little.

        Activity

        Hide
        Jens Alfke added a comment -

        This actually goes back to 0.10.0.
        From some historical evidence (a unit test in the CouchObjC library that used to work but now breaks) it looks like this changed sometime after 0.8.

        Is this considered a bug to be fixed, or just a design limitation?

        Show
        Jens Alfke added a comment - This actually goes back to 0.10.0. From some historical evidence (a unit test in the CouchObjC library that used to work but now breaks) it looks like this changed sometime after 0.8. Is this considered a bug to be fixed, or just a design limitation?
        Hide
        Chris Anderson added a comment -

        this is just a failure to push the conflicts=true parameter through to the include docs code. patches welcome.

        Show
        Chris Anderson added a comment - this is just a failure to push the conflicts=true parameter through to the include docs code. patches welcome.
        Hide
        Filipe Manana added a comment -

        Following patch fixes it.

        JS test included.

        cheers

        Show
        Filipe Manana added a comment - Following patch fixes it. JS test included. cheers
        Hide
        Filipe Manana added a comment -

        Is this ticket still relevant or it's supposed to be abandoned?

        Show
        Filipe Manana added a comment - Is this ticket still relevant or it's supposed to be abandoned?
        Hide
        Patrick Barnes added a comment -

        This is a relevant issue to me, because I want to watch _changes for conflicted documents - and would rather avoid making an extra request for every document, just to see whether it's conflicted or not.

        Ideally, any query that supports the include_docs parameter would also support any of those similar single document API parameters.

        Show
        Patrick Barnes added a comment - This is a relevant issue to me, because I want to watch _changes for conflicted documents - and would rather avoid making an extra request for every document, just to see whether it's conflicted or not. Ideally, any query that supports the include_docs parameter would also support any of those similar single document API parameters.
        Hide
        Filipe Manana added a comment -

        Hi patrick, I'm +1 for this ticket.
        The patch needs to be reworked, since it's too aged.

        Let's see if no one has a -1 on the feature itself.

        Show
        Filipe Manana added a comment - Hi patrick, I'm +1 for this ticket. The patch needs to be reworked, since it's too aged. Let's see if no one has a -1 on the feature itself.
        Hide
        Adam Kocoloski added a comment -

        I'm +1 on both directions outlined by Brian.

        Patrick, a possible alternative in the case of _changes is to perform the query with ?style=all_docs, which will cause all leaf revisions (the winning one and all conflicts) to show up in the row. It doesn't discriminate between unresolved and resolved/deleted conflicts, but you could push a filter function to to suppress the deleted conflicts if you wanted.

        Show
        Adam Kocoloski added a comment - I'm +1 on both directions outlined by Brian. Patrick, a possible alternative in the case of _changes is to perform the query with ?style=all_docs, which will cause all leaf revisions (the winning one and all conflicts) to show up in the row. It doesn't discriminate between unresolved and resolved/deleted conflicts, but you could push a filter function to to suppress the deleted conflicts if you wanted.
        Hide
        Filipe Manana added a comment -

        Fixed on trunk, 1.1.x and 1.0.x.

        Show
        Filipe Manana added a comment - Fixed on trunk, 1.1.x and 1.0.x.

          People

          • Assignee:
            Filipe Manana
            Reporter:
            Brian Candler
          • Votes:
            3 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development