Please, take into account several other circumstances:
– This is obviously not intended for permalinks. Permalinks would require the slug to be saved on the database, without any doubt.
– For this solution to work, the ID must be there. There is no other way. You need resources of the form “#{id}-whatever”
– This is not the ‘holy grail’ for slugs. It’s really up to you where you want to use this solution. I will not personally use this just *everywhere* in my project, but where I believe it makes sense.
– I do care about code perfection, as well as data perfection. This meaning that when I see data duplication *somehow* I start to worry. That said, and as I stated before, there are two exceptions to this personal rule: you need permalinks, or you want to strip out the ID from the resource ID on the route.

friendly_id is cool. However the project that I am working on has some restrictions that simply don’t let me use it.

The main reason of this post is that when I searched about slugs all I could find is ‘store in on the database’, with some sugar: ‘if you want permalinks, just let it be, if you don’t want permalinks, use ActiveRecord callbacks to update your slug’. I think is a nice summary of what I found out there.

So I took some minutes to think and ask myself if I *always* need to save slugs on the database. And found out that the answer is no.

That said, I have used friendly_id in personal projects and I personally love it.

You were also right when you said that this code could have been ‘gemified’, and probably will be. Overall, I think this gem will have less LOC than friendly_id. With friendly_id you have to add two LOC per model. With this solution you would need to add none (initializer on ActiveRecord::Base), or one: (Slug is included per model, ‘include Slug’). So overall, your code will have less slug-related code too.

However, I still think they serve different purposes. Of course I prefer ‘/states/washington’ over ‘/states/74-washington’, but you also need to balance, and think about what are the costs of that. On certain parts of my website/service I prefer not to save this information in the database, and allow my code to infer it.

Thanks again for your comment.

The main axioms are:

1) That maintaining an additional column for storing the slugs is wrong, because there is information duplication, which means maintenance costs in the long term, and there are lots of issues with that.
2) That slugs can always be programmatically deduced from other fields.

I’d like to first address 1). It is actually *very easy* to use a column for storing slugs; there are several gems that implement that very well. They also come with an extensive test suite, and have been used by lots of peers (btw, my favorite gem for this stuff is friendly_id).

The whole process involves adding a gem, bundle installing, adding a migration, migrating, and adding 1 line to one model. And there you go, you have something working, with most of the issues solved.

Your current proposed solution involves writing and maintaining more code. You could argue that you could package your software as a gem, so it would work just as easily as friendly_id. And that would probably be true. But friendly_id is already here, already works, and has already been tested by my peers.

Please don’t take this the wrong way. I appreciate your efforts. But I don’t care about code purity, if I have to choose between maintaining 30 LOC and maintaining 2. *Right now* your solution just seems worse to me, in all the code-related aspects that I care about, than the already existing solutions.

There is the additional stylistic bit that I don’t like having the ids there on the slug, if at all possible. friendly_id allows me to do that very easily, since each slug is a unique id in the database.

Now to address 2): In my experience, as soon as the slugs are viewed by humans, 2) goes out of the window. URLs have lots of importance to certain types of humans, and for some reason they end up being *clients*.

You come up with a pretty convenient way to generate slugs automatically, and they just don’t like it!

Or what’s worse! They come up with *logical* reasons for which the urls ought to be modifiable by them!

Take the quintessential example: a blog post. Imagine that someone creates a post called “My euruko 2012 slides”. Usually the slug would be “my-euruko-2012-slides”. The thing is, the blog automatically adds the date to the url, as in “/2012/06/06/my-euruko-2012-slides”, so the user wants to go and remove the 2012 from the slug, to end up with something like “/2012/06/06/euruko-slides”.

Another example: a page on a CMS. Let’s say that pages can be”nested”. One page could be titled “Contractor taxation documentation”, but given that this page is a “child” of “taxes”, which is a child of “contractors”, the slug could be “documentation”, so the url was nice and short: “/contractors/taxes/documentation” instead of “/contractors/taxes/contractor-taxation-documentation”.

I guess that if you were *really sure* that humans would never want to modify the urls, then … nah, even in that case, I would recommend just adding the slug and the form field. It’s not worth the hassle to fight an end user over such a trivial thing to include.

This said, I really appreciate your effort. Consider sending a patch to friendly_id so that it has a “tableless” mode

@Nicolas: basically, like this (as zayed already pointed out, it was awaiting for moderation): https://bugs.kde.org/attachment.cgi?id=43803

@heynonynor: if I run systemsettings –reverse, I get the treeview on the right hand side, so I think that is fixed now (by someone else, I didn’t fix that).