Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed simple typos #996

Merged
merged 8 commits into from
Jun 7, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions AUTHORS.rst
Original file line number Diff line number Diff line change
Expand Up @@ -25,6 +25,7 @@ Authors
- Carlos San Emeterio (`Carlos-San-Emeterio <https://github.com/Carlos-San-Emeterio>`_)
- Christopher Broderick (`uhurusurfa <https://github.com/uhurusurfa>`_)
- Christopher Johns (`tyrantwave <https://github.com/tyrantwave>`_)
- Conrad (`creyD <https://github.com/creyD>`_)
- Corey Bertram
- Craig Maloney (`craigmaloney <https://github.com/craigmaloney>`_)
- Damien Nozay
Expand Down
1 change: 1 addition & 0 deletions CHANGES.rst
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,7 @@ Changes
Unreleased
----------

- Fixed typos in the docs
- Removed n+1 query from ``bulk_create_with_history`` utility (gh-975)
- Started using ``exists`` query instead of ``count`` in ``populate_history`` command (gh-982)

Expand Down
2 changes: 1 addition & 1 deletion docs/common_issues.rst
Original file line number Diff line number Diff line change
Expand Up @@ -253,7 +253,7 @@ Working with BitBucket Pipelines
--------------------------------

When using BitBucket Pipelines to test your Django project with the
django-simple-history middleware, you will run into an error relating to missing migrations relating to the historic User model from the auth app. This is because the migration file is not held within either your project or django-simple-history. In order to pypass the error you need to add a ```python manage.py makemigrations auth``` step into your YML file prior to running the tests.
django-simple-history middleware, you will run into an error relating to missing migrations relating to the historic User model from the auth app. This is because the migration file is not held within either your project or django-simple-history. In order to bypass the error you need to add a ```python manage.py makemigrations auth``` step into your YML file prior to running the tests.


Using custom OneToOneFields
Expand Down
2 changes: 1 addition & 1 deletion docs/historical_model.rst
Original file line number Diff line number Diff line change
Expand Up @@ -52,7 +52,7 @@ You're able to set a custom ``history_date`` attribute for the historical
record, by defining the property ``_history_date`` in your model. That's
helpful if you want to add versions to your model, which happened before the
current model version, e.g. when batch importing historical data. The content
of the property ``_history_date`` has to be a datetime-object, but setting the
of the property ``_history_date`` has to be a ``datetime``-object, but setting the
value of the property to a ``DateTimeField``, which is already defined in the
model, will work too.

Expand Down
6 changes: 3 additions & 3 deletions docs/querying_history.rst
Original file line number Diff line number Diff line change
Expand Up @@ -144,7 +144,7 @@ If you use `as_of` to query history, the resulting instance will have an
attribute named `_history` added to it. This property will contain the
historical model record that the instance was derived from. Calling
is_historic is an easy way to check if an instance was derived from a
historic timepoint (even if it is the most recent version).
historic point in time (even if it is the most recent version).

You can use `to_historic` to return the historical model that was used
to furnish the instance at hand, if it is actually historic.
Expand All @@ -155,7 +155,7 @@ HistoricForeignKey

If you have two historic tables linked by foreign key, you can change it
to use a HistoricForeignKey so that chasing relations from an `as_of`
acquired instance (at a specific timepoint) will honor that timepoint
acquired instance (at a specific point in time) will honor that point in time
when accessing the related object(s). This works for both forward and
reverse relationships.

Expand Down Expand Up @@ -219,7 +219,7 @@ To filter changes to the data, a relationship to the history can be established.

Poll.objects.filter(history__history_user=4)

You can also prefetch the objects with this relationship using somthing like this for example to prefetch order by history_date descending:
You can also prefetch the objects with this relationship using something like this for example to prefetch order by history_date descending:

.. code-block:: python

Expand Down
4 changes: 2 additions & 2 deletions docs/quick_start.rst
Original file line number Diff line number Diff line change
Expand Up @@ -141,14 +141,14 @@ tables in your database:

.. _above: `Track History`_

The two extra tables with ``historical`` prepended to their names are tables created
The two extra tables with ``historical`` prepend to their names are tables created
by ``django-simple-history``. These tables store every change that you make to their
respective base tables. Every time a create, update, or delete occurs on ``Choice`` or
``Poll`` a new row is created in the historical table for that model including all of
the fields in the instance of the base model, as well as other metadata:

- ``history_user``: the user that made the create/update/delete
- ``history_date``: the datetime at which the create/update/delete occurred
- ``history_date``: the ``datetime`` at which the create/update/delete occurred
- ``history_change_reason``: the reason the create/update/delete occurred (null by default)
- ``history_id``: the primary key for the historical table (note the base table's
primary key is not unique on the historical table since there are multiple versions of it
Expand Down
2 changes: 1 addition & 1 deletion docs/user_tracking.rst
Original file line number Diff line number Diff line change
Expand Up @@ -58,7 +58,7 @@ Admin integration requires that you use a ``_history_user.setter`` attribute wit
your custom ``_history_user`` property (see :doc:`/admin`).

Another option for identifying the change user is by providing a function via ``get_user``.
If provided it will be called everytime that the ``history_user`` needs to be
If provided it will be called every time that the ``history_user`` needs to be
identified with the following key word arguments:

* ``instance``: The current instance being modified
Expand Down
2 changes: 1 addition & 1 deletion docs/utils.rst
Original file line number Diff line number Diff line change
Expand Up @@ -43,7 +43,7 @@ If you find yourself with a lot of old history you can schedule the

$ python manage.py clean_old_history --auto

You can use ``--auto`` to remove old historial entries
You can use ``--auto`` to remove old historical entries
with ``HistoricalRecords`` or enumerate specific models as args.
You may also specify a ``--days`` parameter, which indicates how many
days of records you want to keep. The default it 30 days, meaning that
Expand Down
2 changes: 1 addition & 1 deletion simple_history/locale/de/LC_MESSAGES/django.po
Original file line number Diff line number Diff line change
Expand Up @@ -38,7 +38,7 @@ msgstr "%s wiederherstellen"

#: simple_history/models.py:314
msgid "Created"
msgstr "Angelegt"
msgstr "Erstellt"

#: simple_history/models.py:314
msgid "Changed"
Expand Down
3 changes: 0 additions & 3 deletions simple_history/utils.py
Original file line number Diff line number Diff line change
@@ -1,6 +1,3 @@
import warnings

import django
from django.db import transaction
from django.db.models import Case, ForeignKey, ManyToManyField, Q, When
from django.forms.models import model_to_dict
Expand Down