STI test failure when looking up record from SubClass

[ScotterC]

class Journalist < ActiveRecord::Base
  extend FriendlyId
  friendly_id :name, :use => :slugged
end

class Editorialist < Journalist
  extend FriendlyId
  friendly_id :name, :use => :slugged
end

editorialist = Editorialist.create name: "foo"

Editorialist.find editorialist.slug
# => Couldn't find Editorialist 

Also:

class Journalist < ActiveRecord::Base
end

class Editorialist < Journalist
  extend FriendlyId
  friendly_id :name, :use => :slugged
end

Editorialist.create name: "foo"
# => Couldn't create Editorialist 
`undefined method `exists_by_friendly_id?'`

[parndt]

Thanks for this.. my first impression is that somewhere we're not referencing the base_class where we should be.

[ScotterC]

Got a little closer just now.

Editorialist.friendly.find editorialist.slug works. So it must be something with the finder method module not being added to subclasses?

[parndt]

Oh, right, no that's totally expected.. FriendlyId scopes don't apply unless you use .friendly.find. Try it on the base class and you'll get the same result. I think, given that, this should probably be closed.

[ScotterC]

Well the reason I came across this is because of what I have in my code:

class Product < ActiveRecord::Base
  extend FriendlyId
  friendly_id :name, :use => [:slugged, :finders]
end

class GiftCard < Product
end

gift_card = GiftCard.create name: "foo"

GiftCard.find gift_card.slug #=> AR::NotFound

So the finders module is not being inherited to the subclass. Is that intentional?

[parndt]

Your example code and test case didn't specifically include the :finders module, unless I'm mistaken?

I don't think that the module should automatically inherit to the subclass... @norman what do you think?

[coveralls]

Changes Unknown when pulling 09606c0 on ScotterC:sti-test-failure into * on norman:master*.

[ScotterC]

I just now added the finders module to the test case. Your right. before it should have failed. But it still fails with the module added.

[parndt]

Does your test case pass if you add the same friendly_id line to the subclass?

[ScotterC]

Added. And yes it does still fail. Any ideas on why they wouldn't be inherited? It's the same extension of class methods in the finders module no?

[coveralls]

Changes Unknown when pulling 2d7fba5 on ScotterC:sti-test-failure into * on norman:master*.

[coveralls]

Changes Unknown when pulling 2d7fba5 on ScotterC:sti-test-failure into * on norman:master*.

[ScotterC]

this was just a spacing issue. nothing changed.

[ScotterC]

Cleaned up the PR so it doesn't overwrite the other tests.

The finder methods are just not being included in the sub classes. From what I can tell, FriendlyId::Configuration is not being initialized in subclasses when friendly_id is included.

This is because the extension of the class returns if it responds to friendly_id and therefore the configuration is not initialized and finder_methods are not included.

I see two approaches depending on what the core team wants. Have the finder methods get inherited to sub classes if they are included in the parent or change the extended method to allow a new configuration per class.

[coveralls]

Changes Unknown when pulling 910cdc9 on ScotterC:sti-test-failure into * on norman:master*.

[coveralls]

Changes Unknown when pulling d957e8e on ScotterC:sti-test-failure into * on norman:master*.

[emoreth]

Any news on this one ? I got the same exact problem. Any workarounds to not have to use GiftCard.friendly.find 'slug' ?

[ScotterC]

That's my current workaround.

With 5.0 it seems that the core wants finder methods to be optional. However, the design of finder methods getting included into each subclass seems a bit tricky. I can't figure out why they're in the model's ancestors but the methods aren't included.

[jaredbeck]

.. the finders module is not being inherited to the subclass. ..
I can't figure out why they're in the model's ancestors but the methods aren't included.

I'm seeing this too, in rails 4.0.2 and friendly_id 5.0.2. Changing my app to use Model.friendly.find would be a major effort, so this issue is kind of blocking my upgrade to rails 4. Thanks to everyone working on this, looking forward to an update.

[niklas]

I have the same problem as @jaredbeck. Luckily, we have a module encapsulating our Slug behaviour (friendly id is the third library we use). The :finders module is switched on in an initializer.

Somehow, this fixes the problem of having to use .friendly to find our STI models.

# Include Shop::Slugs in a Model to get application-wide solid slug behaviour
#
# Please define #to_slug on your model, so that this works.
module Shop
  module Slugs
    def self.included(model)
      super
      model.class_eval do
        extend FriendlyId
        friendly_id :to_slug, :use => [:history]
        extend Inheriting
      end
    end

    # friendly_id keeps a config per class, but does not inherit the :finders
    # module, so we have to re-apply the settings
    module Inheriting
      def inherited(child)
        super
        child.class_eval do
          include ::Shop::Slugs
        end
      end
    end
  end
end

[niklas]

Sadly, my approach above causes an early DB access while booting the Rails app, because friendly_id attaches finder_methods to relation, which has to look for the type column. (all caused by active admin loading the routes and with it all models). Migrating the DB from scratch is not possible anymore. Trying to find another way..

[niklas]

Checking for child.table_exists? fixes the migrate problem for now. Would still be great if :finders module would be inherited 🍰

[jaredbeck]

Any word from @parndt or @norman on this? We can't really say FriendlyId supports rails 4 if it doesn't support STI ..

[jaredbeck]

As an ugly workaround, it looks like we can put something like this in each of our child classes:

class MySTIChildClass
  class << MySTIChildClass
    alias_method :super_find, :find
  end

  def self.find(*args)
    friendly.super_find(*args)
  end
end

[norman]

@ScotterC Thanks for the work on this. I've fixed the test failures and merged your changes. This will go out in the next few minutes to Rubygems.

[ScotterC]

Cool. From the commits it looks like you found the root of the issue. Thanks @norman

[jaredbeck]

I just tried 5.0.3. Looks like find is friendly once again in STI subclasses. Thanks @norman. However, it seems that it's necessary to duplicate the call to friendly_id(:foo, use: [:finders]) in the child classes. Can you confirm that it's necessary to duplicate this configuration? Thanks.

[parndt]

Shouldn't subclasses have to opt in?

[norman]

Yes, @jaredbeck, you must call friendly_id in each class. That's by design.

[jaredbeck]

That makes sense. One last thing: The documentation (http://norman.github.io/friendly_id/file.Guide.html) says:

you must extend FriendlyId in all classes that participate in STI, both your parent classes and their children.

but it doesn't mention invoking the friendly_id method. Thanks!

[norman]

You don't have to invoke friendly_id in the parent class if you're only
going to use it in the child classes. But you do need to extend FriendlyId.

Sent from my phone