Uploaded image for project: 'C Driver'
  1. C Driver
  2. CDRIVER-4306

Inconsistencies between update, delete, and insert CRUD functions

    • Type: Icon: Improvement Improvement
    • Resolution: Unresolved
    • Priority: Icon: Minor - P4 Minor - P4
    • None
    • Affects Version/s: None
    • Component/s: libmongoc

      While implementing support for let in CDRIVER-4198, I realized that there are various differences to how _mongoc_collection_update_or_replace and _mongoc_delete_one_or_many are implemented. Both of those functions are the common helpers for their respective CRUD methods.

      A few, but not all, inconsistencies are as follows:

      • _mongoc_delete_one_or_many is missing the "collection" prefix found on the update/replace helper.
      • The delete_one and delete_many methods pass an initialized bson_t as a limit parameter, which is the used to append individual options for the delete statement and later passed as the opts parameter _mongoc_write_command_init_delete_idl. That document is later destroyed in the corresponding public CRUD method. In _mongoc_collection_update_or_replace, the equivalent structure exists entirely within the helper method.
      • _mongoc_delete_one_or_many asserts that the incoming bson_t *reply is empty or null. No such assertion is made in the update helper.
      • _mongoc_collection_update_or_replace checks that an explicit write concern is not being used within a transaction, while _mongoc_delete_one_or_many has no such check.
      • _mongoc_delete_one_or_many receives extra opts (from mongoc_delete_one_opts_t and mongoc_delete_many_opts_t) and passes those as the cmd_opts parameter to _mongoc_write_command_init_delete_idl. In _mongoc_collection_update_or_replace, the extra opts are used to append options for the update statement and later passed as the opts parameter to _mongoc_write_command_init_update_idl (akin to how the limit document in the delete methods is used).

      Of these inconsistencies, I believe only the transaction error checking is relevant to users. The other issues seem mostly internal, but could improve maintainability if addressed.

            Assignee:
            Unassigned Unassigned
            Reporter:
            jmikola@mongodb.com Jeremy Mikola
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: