For URLs, I would prefer to use slugs because they are human-readable. But, I have read and heard that there is a “synchronization issue” when using slugs with multiple front ends and that a UUID is a better approach in this circumstance.
What is that sync issue? And how does a UUID avoid that issue?
Also, does it make sense to have both a UUID and a unique slug? I would think not since if the slug is already unique a UUID seems unnecessary.
Thanks!
I would love to see the reference to this in context. While I can imagine some edge cases where this could be an issue, I would guess it’s not relevant to 99+% of the situations people would expect to encounter.
In part it depends upon your application and table structures. If you have multiple applications with different models identified by slugs, then the slugs aren’t necessarily globally unique - they would only be unique within the application. This may (or may not) be an issue depending upon how your urls are structured.
Mmmm, I see. Thanks!
Both references that I was thinking of are from Will Vincent. First, in this paragraph from his book Django for Professionals (see the last vague sentence specifically):
“There are two alternative approaches. The first is called a “slug,” a newspaper term for a short label for something that is often used in URLs. For example, in our example of “Django for Professionals” its slug could be django-for-professionals. There’s even a SlugField model field that can be used and either added when creating the title field by hand or auto-populated upon save. The main challenge with slugs is handling duplicates, though this can be solved by adding random strings or numbers to a given slug field. The synchronization issue remains though.”
And also in this podcast episode:
https://djangochat.com/episodes/urls-slugs-uuids-P9CPo6pA
I’m going to guess that the general issue being referenced regarding synchronization is addressed earlier in that section - it’s the implication I’m reading into the way that last sentence is phrased. (I don’t have the book so I can’t look it up - you could probably ask him directly, I believe he provides contact information in the book.)
I’ll go further and make the conjecture that the synchronization issue arises when two people are submitting posts at nearly the same time to where two entries with the same slug are attempted to be submitted. If that slug field doesn’t have a unique constraint on it, you could end up with two posts having the same slug. If you do have a unique constraint, you’ll need to handle the situation of the exception being thrown on that duplicate entry.
This is where I go back to my previous response that it’s probably not going to be a problem for 99+% of the people doing this. Unless I knew I had a very high level of activity in areas that would likely cause slug-conflict, I’d be willing to apply a unique index on the slug, and in the case of the error, return a very generic error message to the user that would effectively mean “please try again”.
Now, of course, I’m going to toss a very large caveat into this by saying there may well be another issue I’m not aware of, and that the problems could occur much more frequently than I’m guessing they would - in which case more care must be taken to prevent or resolve these issues.
Ahh, right, I bet that could be it–the submitting of say two posts at the same time with the same title.
And you are correct, he does refer to the issue in the previous paragraph but without any explanation.
Thanks!
I was reading the same book and got confused on the same. There was one more issue discussed on other websites. For new entity creation, the ORM needs to check with DB for the current index. Even with slug, the chance of getting duplicates is higher.
I suspect if the author is referring this back and forth of ORM and db in deciding upon primary key as synchronisation issue. Though I wish the author had clarified it.