Почему стойка / тест объединяет хэши в один при выполнении операций POST или PUT
В моем тесте rspec я определил следующий массив хэшей и выполнил POST:
body = {:event => { :invitations_attributes =>
[ {:recipient_id => 40}, {:email => 'a@a.com'}, {:facebook_id => 123456789} ] } }
post "#{@url}.json", body.reverse_merge(:auth_token => @token)
Исходя из вышеизложенного, я ожидал, что сервер Rails получит invitations_attributes в виде массива хэшей. Однако файл developer.log имеет следующее:
Parameters: {"auth_token"=>"RSySKfN2L8b5QPqnfGf7", "event"=>{"invitations_attributes"=>
[{"recipient_id"=>"40", "email"=>"a@a.com", "facebook_id"=>"123456789"}]}}
(В вышеприведенных параметрах массив "Приглашение-атрибуты" содержит только 1 хэш.)
Следующее заявление curl:
curl -X POST -H "Content-type: application/json" http://localhost:3000/api/v1/events.json -d '{"auth_token":"RSySKfN2L8b5QPqnfGf7","event":{"invitation_attributes":[{"recipient_id":40},{"email":"a@a.com"},{"facebook_id":123456789}]}}'
приводит к тому, что Rails получает массив хэшей без изменений, о чем свидетельствует запись в файле журнала ниже.
Parameters: {"auth_token"=>"RSySKfN2L8b5QPqnfGf7", "event"=>{"invitation_attributes"=>
[{"recipient_id"=>40}, {"email"=>"a@a.com"}, {"facebook_id"=>123456789}]}}
Rack / test демонстрирует это поведение для операций PUT, а также POST.
Почему стойка / тест объединяет 3 хеша в 1, а не отправляет массив точно так, как он определен? Есть ли настройка, которая заставит стойку демонстрировать поведение, которое я ожидал?
1 ответ
Одним из обходных путей является обеспечение того, чтобы каждый хеш содержал каждый ключ, вставляя ключи-заполнители с нулевым значением следующим образом:
body = {:event => { :invitations_attributes => [
{:recipient_id => 40, :recipient_email => nil, :recipient_facebook_id => nil},
{:recipient_email => user.email, :recipient_id => nil, :recipient_facebook_id => nil},
{:recipient_facebook_id => new_unused_facebook_id, :recipient_email => nil, :recipient_id => nil} ] } }
Приведенный выше хэш заставляет сервер получать 3 отдельных хеша в массиве. Однако вставка ключей-заполнителей неудобна и не обязательна. Кроме того, сценарии, в которых контроллер действует по-разному в зависимости от наличия такого ключа (хотя и редко), не могут быть протестированы.