I am trying to delete a Filter View with the following code:
del = Google::Apis::SheetsV4::DeleteFilterViewRequest.new(:filter_id => 19######)
wrapper = Google::Apis::SheetsV4::BatchUpdateSpreadsheetRequest.new(:requests => [del])
puts service.batch_update_spreadsheet(spreadsheet_id, wrapper, {})
but it is throwing:
C:/Ruby23/lib/ruby/gems/2.3.0/gems/google-api-client-0.9.12/lib/google/apis/core/http_command.rb:211:in `check_status': badRequest: Invalid requests[0]: No request set. (Google::Apis::ClientError)
from C:/Ruby23/lib/ruby/gems/2.3.0/gems/google-api-client-0.9.12/lib/google/apis/core/api_command.rb:102:in `check_status'
from C:/Ruby23/lib/ruby/gems/2.3.0/gems/google-api-client-0.9.12/lib/google/apis/core/http_command.rb:179:in `process_response'
from C:/Ruby23/lib/ruby/gems/2.3.0/gems/google-api-client-0.9.12/lib/google/apis/core/http_command.rb:286:in `execute_once'
from C:/Ruby23/lib/ruby/gems/2.3.0/gems/google-api-client-0.9.12/lib/google/apis/core/http_command.rb:107:in `block (2 levels) in execute'
from C:/Ruby23/lib/ruby/gems/2.3.0/gems/retriable-2.1.0/lib/retriable.rb:54:in `block in retriable'
from C:/Ruby23/lib/ruby/gems/2.3.0/gems/retriable-2.1.0/lib/retriable.rb:48:in `times'
from C:/Ruby23/lib/ruby/gems/2.3.0/gems/retriable-2.1.0/lib/retriable.rb:48:in `retriable'
from C:/Ruby23/lib/ruby/gems/2.3.0/gems/google-api-client-0.9.12/lib/google/apis/core/http_command.rb:104:in `block in execute'
from C:/Ruby23/lib/ruby/gems/2.3.0/gems/retriable-2.1.0/lib/retriable.rb:54:in `block in retriable'
from C:/Ruby23/lib/ruby/gems/2.3.0/gems/retriable-2.1.0/lib/retriable.rb:48:in `times'
from C:/Ruby23/lib/ruby/gems/2.3.0/gems/retriable-2.1.0/lib/retriable.rb:48:in `retriable'
from C:/Ruby23/lib/ruby/gems/2.3.0/gems/google-api-client-0.9.12/lib/google/apis/core/http_command.rb:96:in `execute'
from C:/Ruby23/lib/ruby/gems/2.3.0/gems/google-api-client-0.9.12/lib/google/apis/core/base_service.rb:346:in `execute_or_queue_command'
from C:/Ruby23/lib/ruby/gems/2.3.0/gems/google-api-client-0.9.12/generated/google/apis/sheets_v4/service.rb:176:in `batch_update_spreadsheet'
from google_spreadsheet.rb:69:in `<main>'
Let me know if you need any additional information.
Thanks,
Nathan
Unfortunately the way the sheets API is designed the various requests aren't actually subclasses of the generic request object. Instead, it's a composition pattern. The code is a little more verbose than that:
Sheets = Google::Apis::SheetsV4
batch = Sheets::BatchUpdateSpreadsheetRequest.new(requests: [])
del = Sheets::DeleteFilterViewRequest.new(:filter_id => 19######)
batch.requests.push(Sheets::Request.new(delete_filter_view: del)) # Wrap in Request before adding
puts service.batch_update_spreadsheet(spreadsheet_id, wrapper, {})
Alternate using just hashes:
batch = {
requests: [
{
delete_filter_view: {
filter_id: ...
}
}]
}
puts service.batch_update_spreadsheet(spreadsheet_id, batch, {})
Thanks for the reply - the code you provided work.
But I am confused what purpose does DeleteFilterViewRequest class serve?
Not sure what you're asking. Are you asking purpose vs. the generic request class? Or vs. hashes?
vs. the generic Request class, it's partly a side effect of the underlying API framework & technology and how the Sheets team chose to implement the API. Cases where you'd expect to use polymorphism end up getting expressed using composition -- as a wrapper with a bunch of fields for each possible type. If the client were hand-written, those details could be hidden, but the specific API files are all auto-generated from the API descriptions.
vs. hashes, support for hashes in requests were added as a convenience, that's all. Besides always being used in responses, the classes are useful as a reference and also make things like code completion in IDEs like RubyMine possible.
My apologizes, I misread your reply; I thought hash syntax was the only one that would work.
I am guessing since the code is Auto Generated you won't be accepting pull requests to make the methods/classes more user friendly?
Would you be open to a pull request to create a sample section (not specific to a CLI or web app) or a more detailed readme specific to each API? Just trying to help any future developer from getting stuck on trivial error early on in the process.
PRs are welcome. Can't take PRs on the generated code, but updates to the templates and base classes are acceptable so long as they don't break things. For example, adding new convenience methods is an option if it's something that would be generally helpful.
Samples are also welcome and can go in the /samples dir
Docs for specific APIs might be possible soon. I'm working on updating the generator to create separate gems for each API, in which case they can each have their own README
Wow. I just ran into a similar issue where I couldn't figure out what went wrong. In my case I had copied the request_body from the api explorer, which gave me this:
batch = {
"requests":
[
{
"deleteFilterView":
{
"filterId": 1
}
}
]
}
The API Explorer provides parameters in CamelCase.
The ruby gem requires parameters in snake_case. That was the only problem. Somehow I never picked that up anywhere in the documentation.
So the above example needs to be (you can also convert the string keys to symbols):
batch = {
"requests":
[
{
"delete_filter_view":
{
"filter_id": 1
}
}
]
}
Can someone link me to the documentation where I can find some examples for ruby?
Using the hash syntax mentioned above gives me following error message:
badRequest: Invalid requests[0]: No request set.
Edit: also the other way via nested classes is not working and I get the same error? halp please!
@lichtamberg
I'm not sure if you ever worked it out, but if you are using snake_case and still getting this error, chances are you have a typo with one of your fields. It will throw the same error, so double check your spelling. That is what happened to me at least.
Most helpful comment
Wow. I just ran into a similar issue where I couldn't figure out what went wrong. In my case I had copied the request_body from the api explorer, which gave me this:
The API Explorer provides parameters in CamelCase.
The ruby gem requires parameters in snake_case. That was the only problem. Somehow I never picked that up anywhere in the documentation.
So the above example needs to be (you can also convert the string keys to symbols):