docs: Example violates database design rules.

[guettli]

Quoting the docs

Best way to descibe is on a simple example. Let's say there is a field where you store a custom html > page and you would like to have another field attached to the same model store the same page but > with html tags stripped out,

The main basic concept of database design gets violated here: avoid redundancy.

What do you gain by storing the same data, twice? Once not filtered, once filtered....

[andybak]

Denormalization for performance reasons is perfectly acceptable. It's essentially a form of caching. As long as you're clear which fields are canonical sources of truth then storing data in whatever additional forms are useful is a good optimization strategy.

[guettli]

I use cache systems for caching, not a relational database.

[andybak]

Maybe I needed to put 'essentially' in quotes. I was trying to illustrate a point.

[lehins]

I use this functionality to have a plain text representation of an html page, so I can find a model by searching through text only, I am not sure there is an easy way to do that with caching. But this was just a simple example, the concept of field dependencies goes way beyond it. @guettli, hope that answers your question.

[guettli]

Thank you for answering my question.

BTW, I prefer patterns like this. Keeping the database layout clean:

CREATE UNIQUE INDEX lower_case_username ON users ((lower(username)));

[lehins]

@guettli, I totally agree with you, if it something that can be done by database, it is probably better to let it handle it. Unfortunately some things you can only do in an actual programming language. Here is an example of that.

class TextTesting(models.Model):
    title = fields.CharField(max_length=25, dependencies=[
        Dependency(attname='slug', processor=processors.SlugProcessor())
    ])
    slug = models.SlugField(max_length=20, unique=True)

Upon model creation it will slugify the title, make sure it is unique for the slug field and also make sure it fits into the slug field. More importantly there is no need to override model's save method or mess with django's signals in order to achieve that functionality.

[guettli]

@lehins you agree with me. Thank you :-)

Yes, you can use redundant columns, not nice, but it is not forbidden.

But, please don't use it in examples.

That's what this ticket is about.