New types

• all WriteModel s
  • All write models will have a required field that specifies the namespace. The specification allows to model this how we want.
  • The way users create them will be similar to that of the existing models: by calling a constructor method that takes all required fields and takes an object that bears optional fields. This constructor method will be overloaded with one that does not accept an object bearing options.
    • Note how instead of constructors, constructor methods, e.g., WriteModel.replaceOne(...), will be used. This allows IDEs to list the possibilities for a user to pick from, instead of requiring a user to know the exact class.
    • The approach with normal constructors will be used for creating objects that bear options, e.g., new ReplaceOneOptions().optionA(a).... This is because an IDE can show a user exactly what type is needed in this case. However, if someone thinks that WriteModel.replaceOneOptions().optionA(a)... is going to be better, I am also OK with that.
    • If we have individual options repeated across multiple different types that bear them, we can introduce a common internal super-type to avoid code duplication. The same goes for the write models themselves.
    • Methods like WriteModel.replaceOne(...) will all return the same type WriteModel. Its implementation will be internal, e.g., InternalReplaceOneWriteModel, and have all the public methods a driver may need. This allows us to avoid exposing its getters as API.
    • If we decide to use constructor methods for options, e.g., WriteModel.replaceOneOptions(), such methods will each return a different type, e.g., ReplaceOneOptions.
    • Specific types that bear options, e.g., ReplaceOneOptions, won't expose getters as API. Instead, there will be package-access getters allowing InternalReplaceOneWriteModel to be filled with values from ReplaceOneOptions.
  • When a field may have either a single value or an array, like UpdateOneModel.update specified as (Document | Document[]), we will only accept Collection (or Iterable, if it's obvious that the size() is not important), and won't have an overload accepting a single value. This seems fine as modern Java SE versions allow to create a list using of(document), and the fewer overloads we have, the simpler it is to grasp the API.
• BulkWriteOptions
• BulkWriteResult
  • We will model acknowledged and non-verbose bulk write results by exposing these flags and throwing UnsupportedOperationException s from methods that can't provide any info. This is not good, but is consistent with the existing bulk write API. Also, the combination of the spec requirements and the requirement to support Java SE 8, results in us not being able to have a more reasonable design (the spec requirements on this actually seem quite arbitrary, maybe we could change them).
• InsertOneResult, UpdateResult, DeleteResult
• BulkWriteException

Reused types

• WriteConcernError
• WriteError

New methods (only on MongoClient)

BulkWriteResult bulkWrite(Collection<? extends WriteModel<? extends TDocument>> models) throws BulkWriteException;

BulkWriteResult bulkWrite(Collection<? extends WriteModel<? extends TDocument>> models, BulkWriteOptions options) throws BulkWriteException;


BulkWriteResult bulkWrite(ClientSession, Collection<? extends WriteModel<? extends TDocument>> models) throws BulkWriteException

BulkWriteResult bulkWrite(ClientSession, Collection<? extends WriteModel<? extends TDocument>> models, BulkWriteOptions options) throws BulkWriteException