Uploaded image for project: 'Swift Driver'
  1. Swift Driver
  2. SWIFT-1036

Consider returning non-optional results from write methods



    • Type: Task
    • Status: Open
    • Priority: Major - P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 2.0
    • Component/s: None
    • Labels:


      Currently, we return optional results from all write methods e.g. insertOne returns an InsertOneResult?. We return nil if the write is unacknowledged, and a result otherwise.

      This is kind of weird, because generally people aren't using unacknowledged writes. It kind of seems like the API is designed for the 1% use case when we should be optimizing for the 99%.

      Any changes to this would be be breaking, but I wanted to open a ticket to get us thinking about it before our 2.0 release.

      Note that the CRUD spec does say:

      The acknowledged property is defined for languages/frameworks without a sufficient optional type. Hence, a driver may choose to return an Optional<BulkWriteResult> such that unacknowledged writes don't have a value and acknowledged writes do have a value.

      However, it also says:

      If you have a choice, consider providing the acknowledged member and raising an error if the other fields are accessed in an unacknowledged write. Instead of users receiving a null reference exception, you have the opportunity to provide an informative error message indicating the correct way to handle the situation. For instance, "The insertedCount member is not available when the write was unacknowledged. Check the acknowledged member to avoid this error."

      It's hard to remember the original conversation about this, but I think our rationale was that we couldn't error on property accesses for e.g. InsertOneResult so we should go with the first option.

      Another choice would be to make the properties on the struct optional, and return an empty InsertOneResult if the write is unacknowledged, but I think that just moves the "confusing optional" problem to a different place.

      We could also get rid of the public properties, and just having throwing getter methods, though that adds another level of inconvenience.

      And some other options would be to stop supporting unacknowledged writes altogether, or to add separate variants of every write method that do unacknowledged writes e.g. unacknowledgedInsertOne.

      None of these choices seem particularly ideal, but maybe we can come up with something better.




            Unassigned Unassigned
            kaitlin.mahar Kaitlin Mahar
            0 Vote for this issue
            1 Start watching this issue