Collation support does not reject invalid combinations of fields

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Done
    • Priority: Major - P3
    • 3.3.14
    • Affects Version/s: 3.3.11
    • Component/s: Querying
    • Fully Compatible
    • ALL
    • Query 2016-09-19
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None

      When creation an index with a locale, the server rejects things like this:

      > db.test.createIndex( { a: 1 }, { name: 'en_complex', collation: { locale: 'en', strength: 8 } } );
      {
      	"ok" : 0,
      	"errmsg" : "Field 'strength' must be an integer 1 through 5. Got: 8",
      	"code" : 9
      }
      

      But it does not seem to reject the following:

      > db.test.createIndex( { a: 1 }, { name: 'en_complex_1', collation: { locale: 'en', strength: 3, caseLevel: true } } );
      {
      	"createdCollectionAutomatically" : false,
      	"numIndexesBefore" : 3,
      	"numIndexesAfter" : 4,
      	"ok" : 1
      }
      

      A caseLevel definition only make sense for strength 1 or 2, as per "Optional fields" in the spec, with other levels it would just get ignored.

      When reviewing the drivers specification, david.golden had flagged this. The consensus on the drivers side seemed to be that we should warn users about this "ignored field", but that this should be the responsibility of the server to throw an exception for – just like we rely on the server to that for readConcerns: https://github.com/mongodb/specifications/blob/master/source/read-write-concern/read-write-concern.rst#unknown-levels-and-additional-options-for-string-based-readconcerns

            Assignee:
            David Storch
            Reporter:
            Derick Rethans
            Votes:
            0 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated:
              Resolved: