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.

Sign up for GitHub

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

Jump to bottom

Fixed performance doc spelling / grammar #249

Merged
merged 1 commit into from Oct 14, 2014
Merged

Fixed performance doc spelling / grammar #249

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
14 changes: 7 additions & 7 deletions docs/userguide/performance.rst
View file
Open in desktop
Expand Up @@ -4,7 +4,7 @@ Performance tuning
===================

It is important to remember that by default ``django-guardian`` uses generic
foreign keys to retain relation with any Django model. For most cases it's
foreign keys to retain relation with any Django model. For most cases, it's
probably good enough, however if we have a lot of queries being spanned and
our database seems to be choking it might be a good choice to use *direct*
foreign keys. Let's start with quick overview of how generic solution work and
Expand Down Expand Up @@ -60,8 +60,8 @@ Something similar to:



As there are no real foreing keys pointing at the target model this solution
might not be enough for all cases. In example if we try to build an issues
As there are no real foreign keys pointing at the target model, this solution
might not be enough for all cases. For example, if we try to build an issues
tracking service and we'd like to be able to support thousands of users and
their project/tickets, object level permission checks can be slow with this
generic solution.
Expand Down Expand Up @@ -99,13 +99,13 @@ models:
``content_object`` as underlying queries depends on it.


from now on ``guardian`` will figure out that ``Project`` model has direct
From now on, ``guardian`` will figure out that ``Project`` model has direct
relation for user/group object permissions and will use those models. It is
also possible to use only user or only group based direct relation, however it
also possible to use only user or only group-based direct relation, however it
is discouraged (it's not consistent and might be a quick road to hell from the
mainteinence point of view, especially).
maintainence point of view, especially).

.. note::
By defining direct relation models we can also tweak that object permission
model, i.e. by adding some fields
model, i.e. by adding some fields.