Previously this was always set for all requests. The parameter is only
documented as supported for certain queries, so this was probably wrong.
Mongo version 4.2 fails update queries that have this parameter set making
mongoengine unusable there. Fixes#2148.
I'm doing this because it makes sense to separate which requirements are
needed to develop the package and which are purely needed for static code
analysis. That said, the trigger for this commit was that ReadTheDocs
automatically tries to install everything that's in requirements.txt and,
since `black` isn't available on Python 2.7, it was failing. See
https://readthedocs.org/projects/mongoengine-odm/builds/9371765/.
Refs #2105
When passing host `mongomock://localhost/some-default-database` to `connect` the default database was `"test"` instead of `"some-default-database"`.
Fixes: #2130
Previous implementation of `Document._object_key` was *pretending* to work on
MongoEngine-level fields (e.g. using "pk" instead of "_id" and separating
nested field parts by "__" instead of "."), but then it was also attempting to
transform field names from the `shard_key` into DB-level fields.
This, expectedly, didn't really work well. Most of the test cases added in this
commit were failing prior to the code fixes.
* Rename BaseQuerySet._initial_query to BaseQuerySet._cls_query
This new name more accurately reflects the purpose of the dict. It is either
empty for documents that don't use inheritance or it contains a `{"_cls": ...}`
shape query. There was nothing "initial" about it per se.
* Drop read_preference as a kwarg on BaseQuerySet.__call__/filter
It was a poor design choice to offer two different ways to do the same thing:
1. `SomeDoc.objects(foo=bar, bar=baz).read_preference(...)`
2. `SomeDoc.objects(foo=bar, bar=baz, read_preference=...)`
Option 1 is good because it's immediately obvious which part defines the query
to be used and which part defines the read preference.
Option 2 is bad because you don't immediately know whether `read_preference`
is a query kwarg or a reserved keyword with some special behavior. If you
wanted to be particularly cruel, you could even write
`SomeDoc.objects(foo=bar, read_preference=..., bar=baz)`.
THIS IS A BREAKING CHANGE. From now on you have to use the
`BaseQuerySet.read_preference(...)` method.
* Add a BaseQuerySet.clear_cls_query method + get rid of the class_check kwarg
This is similar to what the previous commit did to read preference except that
in this case we were still missing a `BaseQuerySet` method for clearing the
`_cls` query.
Now, instead of the undocumented, untested, and confusing interface:
`ParentDoc.objects(foo=bar, bar=baz, class_check=False)`
We do:
`ParentDoc.objects(foo=bar, bar=baz).clear_cls_query()`
