Details

    • Type: New Feature
    • Status: Open
    • Priority: Major - P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Planning Bucket A
    • Component/s: Indexing
    • Labels:
      None

      Description

      potential syntax:

      db.foo.ensureIndex(

      { name : 1 }

      ,

      { caseInsensitive : true }

      )
      db.foo.ensureIndex(

      { name : 1 }

      ,

      { caseInsensitive : true , locale : "FR" }

      )
      db.foo.ensureIndex(

      { name : 1 }

      ,

      { caseInsensitive : true , localeKey : "user.country" }

      )

      db.foo.ensureIndex(

      { name : 1 }

      ,

      { caseInsensitive : [ "name" ] }

      )

      reminder, you can aways do this for now:
      { name :

      { real : "Eliot" , sort : "eliot" }

      }
      ensuerIndex(

      { "name.sort" : 1 }

      )

        Issue Links

          Activity

          Hide
          ivan.fioravanti@4ward.it Ivan Fioravanti added a comment -

          Again on this... the fact of not being able to do a case insensitive sort through an index is really becoming a blocking issue in some scenario, especially in big data world.

          We've already faced 2 situations where we need to perform sort and paging on quite large datasets (3M items) in order to display data in a web app.
          The fact of using an additional column with "toLower" representation isn't really feasible because sort can be performed on many different fields.

          I imagine this is a nightmare from implementation point of view, but it's a really important feature when you've to deal with large datasets.
          Can you please give us an update on this topic? In order for us to decide if we have to think about a temporary workaround for our customers?

          Thanks

          Show
          ivan.fioravanti@4ward.it Ivan Fioravanti added a comment - Again on this... the fact of not being able to do a case insensitive sort through an index is really becoming a blocking issue in some scenario, especially in big data world. We've already faced 2 situations where we need to perform sort and paging on quite large datasets (3M items) in order to display data in a web app. The fact of using an additional column with "toLower" representation isn't really feasible because sort can be performed on many different fields. I imagine this is a nightmare from implementation point of view, but it's a really important feature when you've to deal with large datasets. Can you please give us an update on this topic? In order for us to decide if we have to think about a temporary workaround for our customers? Thanks
          Hide
          ceefour Hendy Irawan added a comment - - edited

          +1. Tim Hawkins now that you mentioned it, yes we need SERVER-153.

          but IMHO this one is more priority due to extremely common usage.

          Show
          ceefour Hendy Irawan added a comment - - edited +1. Tim Hawkins now that you mentioned it, yes we need SERVER-153 . but IMHO this one is more priority due to extremely common usage.
          Hide
          john.page John Page added a comment -

          I believe are a couple of workarounds to this one of which is to do with the correct pay to page (i.e. never using $skip as many seem to).

          For a simple case insensitive search create a full text search index on the field, when querying query on the full text search index AND a case insensitive regex on the field to ensure no false positives.

          When paging - the important thing is to query every time for values greater than the last on the page of results - limit X where X is the page size. Sort and skip has you walking through the results or the index taking longer for each page - search > last value and sort is better (assuming an index to ensure you get them in order)

          If you use a case Sensitive index for this you do two searches limit pagesize with the first letter changed case then sort the results on display - so if the last thing on the page was

          'john.page@mongodb.com'

          Query for >= 'john.page@mongodb.com' limit 10
          And in parallel >= 'John.page@mongoDB.com'

          Then sort those results and show the first 10.

          Not perfect but still quite fast.

          You can only do this to page through results from the start - if you want to jump to a specific page it's a lot harder, but if you are indexing on other fields as well possibly not that hard.

          Show
          john.page John Page added a comment - I believe are a couple of workarounds to this one of which is to do with the correct pay to page (i.e. never using $skip as many seem to). For a simple case insensitive search create a full text search index on the field, when querying query on the full text search index AND a case insensitive regex on the field to ensure no false positives. When paging - the important thing is to query every time for values greater than the last on the page of results - limit X where X is the page size. Sort and skip has you walking through the results or the index taking longer for each page - search > last value and sort is better (assuming an index to ensure you get them in order) If you use a case Sensitive index for this you do two searches limit pagesize with the first letter changed case then sort the results on display - so if the last thing on the page was 'john.page@mongodb.com' Query for >= 'john.page@mongodb.com' limit 10 And in parallel >= 'John.page@mongoDB.com' Then sort those results and show the first 10. Not perfect but still quite fast. You can only do this to page through results from the start - if you want to jump to a specific page it's a lot harder, but if you are indexing on other fields as well possibly not that hard.
          Hide
          dotnetwise Laurentiu Macovei added a comment - - edited

          This is a must have in terms of easing very common basic usage. Too bad in 4 years nothing changed

          Show
          dotnetwise Laurentiu Macovei added a comment - - edited This is a must have in terms of easing very common basic usage. Too bad in 4 years nothing changed
          Hide
          turneliusz Tuner added a comment -
          Show
          turneliusz Tuner added a comment - Hope it helps guys, http://derickrethans.nl/mongodb-collation.html

            People

            • Votes:
              313 Vote for this issue
              Watchers:
              220 Start watching this issue

              Dates

              • Created:
                Updated:
                Days since reply:
                42 weeks ago
                Date of 1st Reply: