Many enhancements in relation with Beanita and Beanie

[Guibod]

Beanie is a Pydantic extension that supports asynchronous database operation through Motor. Its author, Roman Right also created a Mongita subpackage named Beanita that enables async operations in Mongita in order to simulate Motor’s behaviour. Roman also applied some extension to Mongita in Beanita.

Beanie also started to use find_one_and_update / find_one_and_replace and such a support is required in Mongita. As a Beanita user, I’d like to port as many things into Mongita so that everybody can benefit from Roman features.

In this PR, you will find the following changes:

• Increased usage on bson.SON ordered dicts, and pymongo.results class
• collection support for:
  • Collection.create_index now accepts name parameter, and uses bson.SON internally.
  • Collection.create_indexes, that uses a loop over the already implemented Collection.create_index
  • Collection.drop_indexes, that uses a loop over the already implemented Collection.drop_index
  • Collection.drop, that is an alias for Database.drop_collection
  • Collection.find_one_and_update (with no support for upsert)
  • Collection.find_one_and_replace
  • Collection.find_one_and_delete
• database support for:
  • Database.command, only for buildinfo item
• Classes DeleteResult, UpdateResult supports raw_result property (used for the updatedExisting value)
  • InsertOneResult, InsertManyResult, DeleteResult, UpdateResult are straight subclasses of pymongo classes since I reintroduced the raw_result property support. I’ve hesitated to remove the classes that are now useless but in order to maintain backward compatibility I preferred to maintain them this way.
  • This implies that all results class are now instanced using a raw_result format returned by a mongo 6.0.5 server
• updating _id field will trigger a MongitaError similarly to Mongo/PyMongo behavior where the error code 66 is raised if you try to run this: db.test.insertOne({foo: "bar"}); db.test.updateOne({foo: "bar"}, {$set: {_id: ObjectId()}}). This behaviour was required by the Collection.find_one_and_update method to assert that _id is not part of the update.
  • This implies a change of behavior of Mongita that was relaxed on this and was not emulating mongo properly.

[Guibod]

@scottrogowski Hello, it’s been a while since my PR is sleeping. I’ve just wanted to check your decision regarding my PR.

I know that you hesitated to implement this because there was a regression risk, and that you didn’t have a lot of time to work on this. Nonetheless, it’s important for me to check where mongita is going in order to validate my plans.

Thanks for your time :)