Why SlugField() in Django?

Question

Django has models.SlugField() which helps us to create some cool looking urls. My question is why specifying it as a field

suppose I have this model

 class Blog(models.Model):
    title = models.CharField()

and if I want to add slug, I could just use

 class Blog(models.Model):
    title = models.CharField()

    def title_slug(self):
       return slugify(self.title)

in urls I could just use

(r'^blog/(?P<id>\d+)/(?P<slug>[-\w]+)/$', 'app.views.blog_view'),

and in views

def blog_view(request, id ,slug):
    get_object_or_404(Blog, pk=id)
    ...

urls will look like

example.com/blog/23/why-iam-here/

There are three things that makes me adopt this method

Slug field does not comes with implicit uniqueness.
get_object_or_404(Blog, pk=id) must be faster than get_object_or_404(Blog, slug=slug).
Adding a slug field to existing models involves data migration.

so why SlugField()? , apart from the cost of dynamically generating slug, what are the disadvantages of above method ?

score 40 · Accepted Answer · edited Oct 22 '15 at 14:59

Why SlugField() in Django? Because:

it's human friendly (eg. /blog/ instead of /1/).
it's good SEO to create consistency in title, heading and URL.

The big disadvantage of your dynamically generated slug, accepting slugs in urls.py and not using the slug to get the right object? It's bad design.

If you supply and accept slugs, but don't check against them, then you have multiple URLs returning the same content. So /1/useful-slug/ and /1/this-is-a-bs-slug/ will both return the same page.

This is bad because it does not make life easy for humans. Your visitors have to supply an id and something that is redundant. Duplicated pages are search engines nightmare. Which page is the right one? Duplicated pages will end up with a low rank. See https://support.google.com/webmasters/answer/40349?hl=en (last p)

You can argue that you implement your own beautifully generated links consistently, but people and bots guess URLs all the time (see your logfiles). When you accept all slugs then humans and bots always guess right.

Also saving a slug to the db saves processing power. You generate the slug one time and reuse it. What will be more (in)efficient looking up the slug or generating it each time?

Slug fields in the admin are useful to give editors the opportunity to edit the slug. Maybe to supply extra information that is not in the title but still worth mentioning.

Bonus: To update migrated data:

from django.template.defaultfilters import slugify

for obj in Blog.objects.filter(slug=""):
    obj.slug = slugify(obj.title)
    obj.save()

Stackoverflow uses a redirect (and I like it): http://stackoverflow.com/questions/17495299/this-will-be-replaced You're welcome! — allcaps, Jul 22 '13 at 15:32
I'd say the slug is useless if you're not planning on writing twice the same thing or if you don't really care about inconsistency. saving Processing power? It's really nothing to generate a url and it's more annoying to have one redundant column in your database. I really don't see the point of this slug() — David 天宇 Wong, Feb 17 '14 at 13:00

score 12 · Answer 2 · edited May 19 '14 at 14:18

Slug field does not comes with implicit uniqueness.

There is no implicit uniqueness with a CharField. You need to specify unique=True if you want to ensure that each row is unique at the DB level. You must do this with both a CharField and a SlugField so no advantage to either

get_object_or_404(Blog, pk=id) must be faster than get_object_or_404(Blog, slug=slug).

There might be a very slight difference due to an index on your primary key, but it's probably negligible. This has nothing to do with using a CharField vs SlugField though - you have just created a different URL that takes an id and are using that to do the lookup.

Adding a slug field to existing models involves data migration.

Adding a CharField to an existing model also required a data migration so there is no advantage here.

SlugFields are simply CharField with an extra bit of validation. Look at the code. You are breaking Django's golden rule of DRY - don't repeat yourself.

Furthermore, if you just use a CharField you don't get any validation at the form level, so you can very easily create a "slug" that doesn't conform to the slugs validation, i.e. it might have spaces or characters that are not allowed in an URL.

Also with this approach, if you change your title, your URL has changed and now all your old links are dead. Having a slug field prevents this.

You are making more trouble for yourself here - just use the SlugField

Thanks for your valuable comment, The points on validation and DRY was good. but my actual question was not the difference between CharField and slugfield, but the diffrence of having a SlugField in database and dynamically generating one. — Ryu_hayabusa, Jul 08 '13 at 14:27
I've answered that: "SlugFields are simply CharField with an extra bit of validation" - there is no difference at the DB level — Timmy O'Mahony, Jul 08 '13 at 17:03
https://docs.djangoproject.com/en/1.7/ref/models/fields/#slugfield SlugField "Implies setting Field.db_index to True." So, it should be indexed by default. — John Pang, Jan 28 '15 at 17:18

score 0 · Answer 3 · answered Sep 01 '20 at 16:21

I am making a multi-tenant calendar app. If the calendar urls were something like: /calendar/id/ where the ids were successive integers, then hackers could guess the ids and find out more about my business than I want. By using a url /calendar/slug/ it is much harder to find all the calendars.

Why SlugField() in Django?

3 Answers3

Linked