Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix exists? to behave the same as find for numeric slugs #875

Merged
merged 2 commits into from
Jun 30, 2018

Conversation

sethbaugh
Copy link
Contributor

If a record is created with a slug that is an integer (123, for example), Model.friendly.find("123") finds the correct record with slug of "123", but Model.friendly.exists?("123") returns false.

Referencing the comment here:

    # If the id is a numeric string like '123' it will first look for a friendly
    # id matching '123' and then fall back to looking for a record with the
    # numeric id '123'.

.find() is correctly finding the record by its slug "123". Code reference

    def find(*args)
      id = args.first
      return super if args.count != 1 || id.unfriendly_id?
      first_by_friendly_id(id).tap {|result| return result unless result.nil?}
      return super if potential_primary_key?(id)
      raise ActiveRecord::RecordNotFound, "can't find record with friendly id: #{id.inspect}"
    end

However, .exists? does not behave in the same way. It immediately passes to super looking for a record with an id of 123 based on .friendly_id?. Code reference

    def exists?(conditions = :none)
      return super unless conditions.friendly_id?
      exists_by_friendly_id?(conditions)
    end

I've updated .exists? to take a similar approach to find in looking for a record with the slug first and only passing it to super if none is found.

@parndt parndt merged commit e8186c6 into norman:master Jun 30, 2018
@parndt
Copy link
Collaborator

parndt commented Jun 30, 2018

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants