friendly_id - Isolating the slugs to a separate table

[arafiu-rpx]

Is there any possibility to have slug field in the common/separate table perhaps with Polymorphic association?

Because we are having large database, So I can not create slug field in all the tables. So I want it to be in separate table with polymorphic association like history add on.

For example I have three models User, Product and Slug but the slug field is not present in users and products table. The slug field is present in slugs table.

User Model

class User < ActiveRercord::Base
  extend FriendlyId
  friendly_id :slug_candidates, use: [:slugged, :finders]
  has_one :slug, dependant: :destory, as: :sluggable, class_name: "FriendlyId::Slug"
end

Product Model:

class Product < ActiveRercord::Base
  extend FriendlyId
  friendly_id :slug_candidates, use: [:slugged, :finders]
  has_one :slug, dependant: :destory, as: :sluggable, class_name: "FriendlyId::Slug"
end

Slug Model

module FriendlyId

  class Slug < ActiveRecord::Base

    belongs_to :sluggable, :polymorphic => true

    def to_param
      slug
    end
  end
end

I want to find the User record using slug content for example

User.find("rafiu") - to fetch the user with slug content of "rafiu"

It should find the user by joining slugs table.

Is there a way to do this?

I already created post in stackoverflow - http://stackoverflow.com/questions/23866305/friendly-id-isolating-the-slugs-to-a-separate-table

[ghost]

+1

[norman]

Sorry, not going to do this. This was how FriendlyId 3.x and below worked. If you have very large tables, performance is significantly worse with the slug in a separate table.

[SanderMander]

What if you need one path for everything?
E.g. /my-username, /blog-post, /news-title ?
get '*slug' , :to=> MyRouter - may help
If there will be ability to add one table for all slugs, then Inside MyRouter you will be able to select slugged_type where slug and use it to build controller name. In case of different tables you need to select as many times as you have slugged models. And to improve perfomance you may add cached_slug to each model table (see act_as_votable gem). So if you need to search in all slugs you will use global table. If you will need to get exactly one model, then you may use cached_column

[norman]

And to improve perfomance you may add cached_slug

No, that's for FriendlyId 3.0 and less, from 2+ years ago. There's always an in-table slug now.

[mengqing]

Is there anyway to use the friendly_id_slugs table instead of the in table column? We can't create the slug column in an existing table, but we can create additional tables (friendly_id_slugs), since this table is being used when the history module is used, I doubt the performance is going to be any worse.

[norman]

No, at the moment you need to use the in-table slug. The performance of
external slugs is significantly worse, that's why it's designed the way it
is (see the benchmarks linked in the README). I know there's a use case for
external-only slugs despite the performance difference, so if somebody
wants to work on that I'd be fine with making that change, but it's a fair
bit of work and very low on my personal list of priorities for this library.
On Wed, Aug 26, 2015 at 21:36 Jimmy Zhang notifications@github.com wrote:

Is there anyway to use the friendly_id_slugs table instead of the in table
column? We can't create the slug column in an existing table, but we can
create additional tables (friendly_id_slugs), since this table is being
used when the history module is used, I doubt the performance is going to
be any worse.

—
Reply to this email directly or view it on GitHub
#558 (comment).

[Silex]

@norman: if the slugs are always in-table, why does rails generate friendly_id generate a migration at all? why is this recommended in the README?

[norman]

Because if you want to use the (popular) history module, you need the table.

It's a common usage pattern for somebody to set up FriendlyId, not use the history module right away, and then decide to use it on a model, some time after the initial setup. If they created the table as per the instructions, everything works as expected. If they did not, it often ends up leading to a ticket asking "Why doesn't history work."

If you find it annoying to have an extra table around that you're not using, then you can just drop the table and/or delete the migration - just remember you'll need to add it back if at some point you want to use the history feature.

[kimrgrey]

By the way, there is a special flag in generator to skip this migration: https://git.io/vzO6x. May be it's good idea just clarify how to use it in documentation or README?

[norman]

@kimrgrey Sure, I think it would be fine to mention that in the docs. I would not put it in the README though; it's a minor detail and the README should be very focused on the absolute basics you need to do to get the library running. There's zero practical impact on an application from having an empty table in its schema, but there is a very practical impact from NOT having it there when you want to use it six months after you last read about how to set up FriendlyId and don't remember that it came with a migration that you skipped. So I don't think its worth mentioning prominently.

[Silex]

@norman: thanks for the clarifications... if they could make their way to the README, along with how to use the History module that'd be great. Right now the usage docs are pretty hard to find (managed to find http://norman.github.io/friendly_id/FriendlyId/History.html but that was not easy, and it's very miminal).

[kimrgrey]

@Silex, well, friendly_id has detailed documentation for all features here: http://norman.github.io/friendly_id/file.Guide.html. And this page is referenced on top of the README.

[Silex]

@kimrgrey: doh... somehow I managed to miss it 😭

Thanks

[januszm]

I'd still add just a note, maybe with (*) to the README, about the migration+History module.

[copasetickid]

@norman Is it still recommended to use the in-table slug? I'm just curious has there been any progress in improving the performance of an external slugs table? If not would recommend that an app not use this gem if it has a use case for Slug only table that referred to it's polymorphic type

cc @parndt

No, at the moment you need to use the in-table slug. The performance of
external slugs is significantly worse, that's why it's designed the way it
is (see the benchmarks linked in the README). I know there's a use case for
external-only slugs despite the performance difference, so if somebody
wants to work on that I'd be fine with making that change, but it's a fair
bit of work and very low on my personal list of priorities for this library.

#558 (comment)

[parndt]

Hi @copasetickid thanks for the question. It has not been an area of focus, so unless you're inclined to tackle it 😁 😅 the recommendation hasn't changed.

[copasetickid]

Thanks, @parndt for clarifying. 😄
I don't have strong inclination to work on it as I think the slug column is better suited on the table itself as recommended than on a separate table. I was asking as it was coming up in a project I'm working and I was just curious where this stood.

Is there value in working on if I ever change my mind or in your experience you found that a separate table is not a good design choice for most use cases?

[norman]

You’ll never be able to make the performance of an external slug rival that of an in-table slug because with an external slug you’ll always either have to do a join or two queries, which is inherently more expensive than not doing a join, or doing only one query. Early versions of the library used only external slugs and it nuked the performance of larger sites. -- Sent from my phone

[copasetickid]

Thanks for sharing that @norman. I appreciate the insight on this and why its designed this way. 😄