Uploaded image for project: 'Java Driver'
  1. Java Driver
  2. JAVA-4416

Undocumented behavior change for createIndex from 'DB' api to 'Document' API?

    • Type: Icon: Bug Bug
    • Resolution: Declined
    • Priority: Icon: Unknown Unknown
    • None
    • Affects Version/s: 3.8.2
    • Component/s: API
    • Labels:

       
      I'm trying to determine if there is undocumented (or at least, the documentation is difficult to find) behavior change re index creation in the MongoDB Java client from the legacy DB based API to the newer Document based API.

      We have an application that started on Mongo 2.4, when if a document had an indexed field with size > 1024B, Mongo would insert the document but not include it in the index.

      When we upgraded to 2.6, which fails when trying to index large fields, we discovered this error the hard way and fixed it in our application. However, the old unindexed documents remained in the collection, and didn't seem to cause any problems.

      We've since upgraded to Mongo 3.6 (but not yet WiredTiger), and up until recently were using the legacy DB API in the Java client version 3.8.2, using createIndex to ensure/create indexes on application startup.

      We finally switched over to the new Document based API without updating the client version and now the app will not start due to com.mongodb.MongoWriteException: Btree::insert: key too large to index errors.

      My assumption here is that the old API would still ignore existing documents with large index values when creating (well, ensuring really, since the indexes have existed for years) indexes, but the new API fails. Is it possible to confirm this? So far I've been unable to do so and I'm worried I'm barking up the wrong tree.

            Assignee:
            valentin.kovalenko@mongodb.com Valentin Kavalenka
            Reporter:
            gaprice@lbl.gov Gavin Price
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: