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

Unexpected behavior introduced in #816 #858

Closed
ppadron opened this issue Dec 20, 2014 · 2 comments
Closed

Unexpected behavior introduced in #816 #858

ppadron opened this issue Dec 20, 2014 · 2 comments
Labels

Comments

@ppadron
Copy link
Contributor

ppadron commented Dec 20, 2014

I think #816 introduced an unexpected behavior in this line: 0fda558#diff-e9e8424a5238d48301e313d8fe285697R41

The updated README states that when includes_missing is false only attributes that have any value will be returned, but the code currently checks if the value evaluates to false instead of nil. Here is a failing test case that should pass:

it 'should not consider as a missing attribute a value that evaluates to false' do
  subject.params do
    requires :first
    optional :false
  end

  subject.post '/declared' do
    error!('expected false', 400) if declared(params, include_missing: false)[:false] != false
    ''
  end

  post '/declared', MultiJson.dump(first: 'one', false: false), 'CONTENT_TYPE' => 'application/json'
  expect(last_response.status).to eq(201)
end

However, I would argue that even attributes with nil values should not be considered "missing", since nil can be a valid value in some cases.

If the idea is to consider nil values as missing, this line should be:

next unless options[:include_missing] || children || !params[parent].nil?

But if nil should be considered a valid value, then we should only check for the attributes presence:

next unless options[:include_missing] || children || params.key?(parent)

What do you think?

@dblock dblock added the bug? label Dec 20, 2014
@dblock
Copy link
Member

dblock commented Dec 20, 2014

I think you're right, make a PR?

@dblock
Copy link
Member

dblock commented Dec 28, 2014

Fixed in c51565c.

@dblock dblock closed this as completed Dec 28, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants