Core Server
  1. Core Server
  2. SERVER-3069

Add extra fields to getLastError output on duplicate key error

    Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Major - P3 Major - P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: planned but not scheduled
    • Component/s: Usability
    • Labels:
      None
    • Backport:
      No
    • # Replies:
      2
    • Last comment by Customer:
      true

      Description

      Should at least have field name and duplicated value.

      See http://stackoverflow.com/questions/5939720/better-ways-to-handle-mongodb-exceptions

        Activity

        Hide
        Aristarkh Zagorodnikov
        added a comment -

        Voted on this, but thought I should write something too.
        The message for error 11000 currently at least be parsed to extract the index name. The message for error 11001 doesn't contain even that information.
        Having index name along with the name of the field and it's value as separate fields in a result document for both errors would be very welcome for run-time and post-mortem (log-based) debugging.

        Show
        Aristarkh Zagorodnikov
        added a comment - Voted on this, but thought I should write something too. The message for error 11000 currently at least be parsed to extract the index name. The message for error 11001 doesn't contain even that information. Having index name along with the name of the field and it's value as separate fields in a result document for both errors would be very welcome for run-time and post-mortem (log-based) debugging.
        Hide
        Eli Skeggs
        added a comment -

        We have a number of collections with multiple unique indexes that could be violated. It looks like our only option to differentiate which index was violated in the event of an E11000 is to parse the error message, which works but is a hacky solution to what I would imagine is not an uncommon problem. This feature would be very much appreciated. Thanks!

        Show
        Eli Skeggs
        added a comment - We have a number of collections with multiple unique indexes that could be violated. It looks like our only option to differentiate which index was violated in the event of an E11000 is to parse the error message, which works but is a hacky solution to what I would imagine is not an uncommon problem. This feature would be very much appreciated. Thanks!

          People

          • Votes:
            17 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

            • Created:
              Updated:
              Days since reply:
              26 weeks, 2 days ago
              Date of 1st Reply: