Previously, when reading a LazyReferenceField from the DB, it was stored
internally in the parent document's _data field as an ObjectId. However, this
meant that equality tests using an enclosing EmbeddedDocument would not return
True when the EmbeddedDocument being compared to contained a DBRef or Document
in _data. Enclosing Documents were largely unaffected because they look at the
primary key for equality (which EmbeddedDocuments lack).
This makes the internal Python representation of a LazyReferenceField (before
the LazyReference itself has been constructed) a DBRef, using code identical to
ReferenceField.
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 is a follow-up after #2107.
Not sure what happened here, but in
87194856ec
I committed a copy-paste of the same test instead of a test validating the
max_length behavior along with a "set" operator.
