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()`
I originally changed the exception name from `ConnectionError` to
`MongoEngineConnectionError` in
b02904ee75,
inspired by landscape.io's package health report, which argued that
`ConnectionError` is already a built-in exception in Python 3 (which it is:
https://docs.python.org/3/library/exceptions.html#ConnectionError).
I do agree that we shouldn't override built-in exceptions. [0] That said, it’s
silly to add a "MongoEngine" prefix to any class within the `mongoengine`
module (and *especially* to *just one* exception class out of many). I've
decided to do what PyMongo does (
8855a510a8/pymongo/errors.py (L59))
and call this exception `ConnectionFailure`.
Note that this is a breaking change and people will need to rename
`MongoEngineConnectionError`s in their code to `ConnectionFailure`. Moreover,
if they use PyMongo's `ConnectionFailure` for anything, they'll need to take
extra care to avoid conflicts, e.g. by using:
```
from mongoengine import ConnectionFailure as MongoEngineConnectionFailure
```
[0] Note that some popular packages still overwrite `ConnectionError`, e.g.
4983a9bde3/requests/exceptions.py (L32)
or
0be4d29206/redis/exceptions.py (L8)
This commit:
1. Formats all of our existing code using `black`.
2. Adds a note about using `black` to `CONTRIBUTING.rst`.
3. Runs `black --check` as part of CI (failing builds that aren't properly formatted).
For example, if you had the following class:
```
class Person(Document):
name = StringField()
age = IntField()
```
You could instantiate an object of such class by doing one of the following:
1. `new_person = Person('Tom', 30)`
2. `new_person = Person('Tom', age=30)`
3. `new_person = Person(name='Tom', age=30)`
From now on, only option (3) is allowed.
Supporting positional arguments may sound like a reasonable idea in this
heavily simplified example, but in real life it's almost never what you want
(especially if you use inheritance in your document definitions) and it may
lead to ugly bugs. We should not rely on the *order* of fields to match a given
value to a given name.
This also helps us simplify the code e.g. by dropping the confusing (and
undocumented) `BaseDocument._auto_id_field` attribute.
For example, if you had the following class:
```
class Person(Document):
name = StringField()
age = IntField()
```
You could instantiate an object of such class by doing one of the following:
1. `new_person = Person('Tom', 30)`
2. `new_person = Person('Tom', age=30)`
3. `new_person = Person(name='Tom', age=30)`
From now on, only option (3) is allowed.
Supporting positional arguments may sound like a reasonable idea in this
heavily simplified example, but in real life it's almost never what you want
(especially if you use inheritance in your document definitions) and it may
lead to ugly bugs. We should not rely on the *order* of fields to match a given
value to a given name.
This also helps us simplify the code e.g. by dropping the confusing (and
undocumented) `BaseDocument._auto_id_field` attribute.
This closes#2096. Previous documentation of the shard_key meta attribute was
missing the crucial point that it really only matters if your collection is
sharded over a compound index.
