Fix typos with codespell --ignore-words-list=unkown --skip="*.po" -w

This commit is contained in:
Christian Clauss 2024-01-10 21:06:29 +01:00
parent 560fa4aea5
commit 0b683ef3d5
6 changed files with 13 additions and 13 deletions

View file

@ -28,7 +28,7 @@ You will find detailed description of the EAV here:
## EAV - The Good, the Bad or the Ugly?
EAV is a trade-off between flexibility and complexity. As such, it should not be thought of as either an amelioration pattern, nor an anti-pattern. It is more of a [gray pattern](https://wiki.c2.com/?GreyPattern) - it exists in some context, to solve certain set of problems. When used appropriately, it can introduce great flexibility, cut prototyping time or deacrease complexity. When used carelessly, however, it can complicate database schema, degrade the performance and make maintainance hard. **As with every tool, it should not be overused.** In the following paragraphs we briefly discuss the pros, the cons and pointers to keep in mind when using EAV.
EAV is a trade-off between flexibility and complexity. As such, it should not be thought of as either an amelioration pattern, nor an anti-pattern. It is more of a [gray pattern](https://wiki.c2.com/?GreyPattern) - it exists in some context, to solve certain set of problems. When used appropriately, it can introduce great flexibility, cut prototyping time or deacrease complexity. When used carelessly, however, it can complicate database schema, degrade the performance and make maintenance hard. **As with every tool, it should not be overused.** In the following paragraphs we briefly discuss the pros, the cons and pointers to keep in mind when using EAV.
### When to use EAV?
@ -55,7 +55,7 @@ As a rule of thumb, EAV can be used when:
- Numerous classes of data need to be represented, each class has a limited number of attributes, but the number of instances of each class is very small.
- We want to minimise programmer's input when changing the data model.
For more throughout discussion on the appriopriate use-cases see:
For more throughout discussion on the appropriate use-cases see:
1. [Wikipedia - Scenarios that are appropriate for EAV modeling](https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model#Scenarios_that_are_appropriate_for_EAV_modeling)
2. [StackOverflow - Entity Attribute Value Database vs. strict Relational Model E-commerce](https://stackoverflow.com/questions/870808/entity-attribute-value-database-vs-strict-relational-model-ecommerce)
@ -106,7 +106,7 @@ INSTALLED_APPS = [
Add `django.db.models.UUIDField` or `django.db.models.BigAutoField` as value of `EAV2_PRIMARY_KEY_FIELD` in your settings
``` python
EAV2_PRIMARY_KEY_FIELD = "django.db.models.UUIDField" # as exemple
EAV2_PRIMARY_KEY_FIELD = "django.db.models.UUIDField" # as example
```
### Note: Primary key mandatory modification field
@ -131,7 +131,7 @@ If the primary key of eav models are to be modified (UUIDField -> BigAutoField,
Change the value of `EAV2_PRIMARY_KEY_FIELD` into the desired value (`django.db.models.BigAutoField` or `django.db.models.UUIDField`) in your settings.
```python
EAV2_PRIMARY_KEY_FIELD = "django.db.models.BigAutoField" # as exemple
EAV2_PRIMARY_KEY_FIELD = "django.db.models.BigAutoField" # as example
```
Run again the migrations.

View file

@ -25,8 +25,8 @@ or with decorators:
class Supplier(models.Model):
...
Generally, if you chose the former, the most appriopriate place for the
statement would be at the bottom of your ``models.py`` or immmediately after
Generally, if you chose the former, the most appropriate place for the
statement would be at the bottom of your ``models.py`` or immediately after
model definition.
Advanced Registration

View file

@ -131,7 +131,7 @@ class Attribute(models.Model):
)
"""
Main identifer for the attribute.
Main identifier for the attribute.
Upon creation, slug is autogenerated from the name.
(see :meth:`~eav.fields.EavSlugField.create_slug_from_name`).
"""

View file

@ -48,7 +48,7 @@ class Entity:
def __getattr__(self, name):
"""
Tha magic getattr helper. This is called whenever user invokes::
The magic getattr helper. This is called whenever user invokes::
instance.<attribute>

View file

@ -83,7 +83,7 @@ def rewrite_q_expr(model_cls, expr):
IGNORE
This is done by merging dangerous AND's and substituting them with
explicit ``pk__in`` filter, where pks are taken from evaluted
explicit ``pk__in`` filter, where pks are taken from evaluated
Q-expr branch.
Args:
@ -101,7 +101,7 @@ def rewrite_q_expr(model_cls, expr):
config_cls = getattr(model_cls, '_eav_config_cls', None)
gr_name = config_cls.generic_relation_attr
# Recurively check child nodes.
# Recursively check child nodes.
expr.children = [rewrite_q_expr(model_cls, c) for c in expr.children]
# Check which ones need a rewrite.
rewritable = [c for c in expr.children if is_eav_and_leaf(c, gr_name)]
@ -317,7 +317,7 @@ class EavQuerySet(QuerySet):
)
.order_by(
# Order values by their value-field of
# appriopriate attribute data-type.
# appropriate attribute data-type.
field_name
)
.values_list(
@ -328,7 +328,7 @@ class EavQuerySet(QuerySet):
)
)
# Retrive ordered values from pk-value list.
# Retrieve ordered values from pk-value list.
_, ordered_values = zip(*pks_values)
# Add explicit ordering and turn

View file

@ -11,7 +11,7 @@ from eav.logic.entity_pk import get_entity_pk_type
class EavConfig(object):
"""
The default ``EavConfig`` class used if it is not overriden on registration.
The default ``EavConfig`` class used if it is not overridden on registration.
This is where all the default eav attribute names are defined.
Available options are as follows: