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.
See https://github.com/MongoEngine/mongoengine/issues/2104 for details.
For now I'm hardcoding `$MONGODB = 3.4.17` just to get a release out there,
but we should probably use the globals going forward. Will do that in
a follow-up commit once I get the `travis-conditions` gem up and running and
hence can test `.travis.yml` changes without deploying.
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.
This more closely aligns with the rule that a single tests should test one
thing and one thing only. Previous code tested like 4 different things in a
single test and was hard to follow.
It covers operations such as:
1. Document initialization.
2. Accessing/setting attributes on a Document instance.
3. Serializing a Document instance (via `to_mongo`).
4. Deserializing a Document instance (via `_from_son`).
5. Serializing + saving a Document in the database (via `save`).
5. Loading a Document from the database + deserializing (via `Doc.objects[0]`).
And it does so for both basic flat documents and more complex nested docs.
1. Removes the cascade=save tests. It's not an option I'd recommend using AND
it primarily matters if you have any reference fields in your document,
which is not the case in this script.
2. Uses PyMongo-v3.x-style write concern.
3. Removes an old docstring describing some random benchmark run from the past.
4. Removes unused parts of the code.
I'll add more tests to the "benchmarks/" directory in future commits.
This time my attempt is based on the output found in another job that didn't
trigger a deployment: https://travis-ci.org/MongoEngine/mongoengine/jobs/544664203
```
/home/travis/.travis/job_stages: line 660: expected `)'
/home/travis/.travis/job_stages: line 660: syntax error near `AND'
/home/travis/.travis/job_stages: line 660: ` if [[ ($TRAVIS_REPO_SLUG = "MongoEngine/mongoengine") && ($TRAVIS_PYTHON_VERSION = 2.7) && ($PYMONGO = 3.x AND $MONGODB = 3.4) && ("$TRAVIS_TAG" != "") ]]; then'
```
See 80ca6360c1f3ea073e3fcb65070ded0558514ffa and
40ba51ac43 for my previous attempts.
Previously, we were running the test suite for several combinations of MongoDB,
Python, and PyMongo:
- PyPy, MongoDB v2.6, PyMongo v3.x (which really means v3.6.1 at the moment)
- Python v2.7, MongoDB v2.6, PyMongo v3.x
- Python v3.5, MongoDB v2.6, PyMongo v3.x
- Python v3.6, MongoDB v2.6, PyMongo v3.x
- Python v2.7, MongoDB v3.0, PyMongo v3.5.0
- Python v3.6, MongoDB v3.0, PyMongo v3.5.0
- Python v3.5, MongoDB v3.2, PyMongo v3.x
- Python v3.6, MongoDB v3.2, PyMongo v3.x
- Python v3.6, MongoDB v3.4, PyMongo v3.x
- Python v3.6, MongoDB v3.6, PyMongo v3.x
There were a couple issues with this setup:
1. MongoDB v2.6 – v3.2 have reached their End of Life already (v2.6 almost 3
years ago!). See the "MongoDB Server" section on
https://www.mongodb.com/support-policy.
2. We were only testing two recent-ish PyMongo versions (v3.5.0 & v3.6.1).
We were not testing the oldest actively supported MongoDB/PyMongo/Python
setup.
This PR updates the test matrix so that these problems are solved. For the
sake of simplicity, it does not yet attempt to cover MongoDB v4.0:
- PyPy, MongoDB v3.4, PyMongo v3.x (aka v3.6.1 at the moment)
- Python v2.7, MongoDB v3.4, PyMongo v3.x
- Python v3.5, MongoDB v3.4, PyMongo v3.x
- Python v3.6, MongoDB v3.4, PyMongo v3.x
- Python v2.7, MongoDB v3.4, PyMongo v3.4
- Python v3.6, MongoDB v3.6, PyMongo v3.x
Stefan Wojcik
