1

I searched on google and found this: "SlugField is a field for storing URL slugs in a relational database. SlugField is a column defined by the Django ORM. SlugField is actually defined within the django.db."

But still, the definition sounds a little complicated to me. I don't even know what a slug is in this context and not sure about Django ORM. I just need a reason why I should use SlugField in Django in simple terms.

Cyebukayire
  • 795
  • 7
  • 14
  • 2
    Some people prefer the URLs that people access their site to contain words relevant to the content instead of just ids - "/articles/news-about-important-thing/" vs "/articles/12312/". These URL friendly strings derived from titles/names are called slugs – Iain Shelvington Sep 17 '21 at 10:17
  • Ohhh I get it:) Thanks @lain – Cyebukayire Sep 17 '21 at 10:32

1 Answers1

3

You don't strictly need to use a SlugField.

"Slug" is a term borrowed from journalism that refers to a short version of a title. As mentioned in a comment to your answer, it's a way to make URLs more explicit while still keeping them somewhat short, instead of using, for example, the full title (which would often be too long), or an ID (which wouldn't be explicit or memorable at all: think of a user who wants to find an article they remember reading: if they start typing some keyword in their address bar, a URL that contains it will pop up, one with an ID will not).

If you wanted you could craft your own slug, by making it URL-friendly (remove any symbol that a URL wouldn't hold, converting anything that would need to be url-encoded, turning spaces into hyphens...) and removing anything unnecessary (e.g. removing words like the, a, an, is, are... or cropping lenghty titles to a maximum number of words or characters).

SlugField is simply a convenience you can use to automate that to some extent. It also comes with some extra features that you might need: for example it automatically generates a slug from a field of your choice, and it can add a unique number to the slug so that you don't accidentally end up with two identical URLs for two different articles that have the same title.

The reason it is a field is that, although you could, it's not smart to calculate a slug every time you access an object: the slug will only change when the title changes, meaning possibly never, so it makes sense to generate it only once and then store it in the database to use it next time, without having to produce it again. This has the added advantage of making a URL to a certain article permanent: you could make it so the slug won't change even if you change the title of the article, which would be a good thing.

Once you have it, since a slug refers unambiguously to a specific object, it acts as a sort of human-readable unique ID, and so it can be used to retrieve the object from the database as efficiently as an opaque numeric ID. It also obscures how many objects you have (if for some reason you want to do that), since a sequential ID of, say, 1543, tells anyone that you probably have 1542 other objects that came before that one.

theberzi
  • 2,142
  • 3
  • 20
  • 34
  • Wow :) It all makes sense now. Thank you so much @theberzi So, there is something you mentioned. is it actually possible that a URL is calculated every time an object is accessed? I mean, what did you mean by calculating? – Cyebukayire Sep 17 '21 at 10:46
  • 1
    When you go to an address like website.com/blog/very-nice-article, the browser sends a request to the server (Django) with that URL and Django has to figure out whether there is something that corresponds to that name. You have for example a url pattern that looks like `/blog/`. In this case `` corresponds to `very-nice-article`: the view receives this as a parameter and has to look into the database for an object that has it as a slug. If you make it so that the slug can change when the title changes, the same url could end up pointing to nowhere, or to a different object. – theberzi Sep 17 '21 at 11:21