gimite
Add ListRow#delete
ListRow#clear only empties a line, delete would remove it so no empty line is left over.
I've looked into the source code but I'm not sure whether there could be a better way than shifting all rows below the deleted one up one row.
Sounds good. I'm happy to accept pull request to implement it.
I've looked into the source code but I'm not sure whether there could be a better way than shifting all rows below the deleted one up one row.
I believe that's the only way.
Actually there is a correct way to do that: https://developers.google.com/google-apps/spreadsheets/#deleting_a_list_row
Basically it does the same thing as you suggested, but it should be a lot more safe to do it with DELETE request.
As written in the url above:
If you want to delete the row regardless of whether someone else has updated it since you retrieved it, then use If-Match: * and don't include the ETag. (In this case, you don't need to retrieve the row before deleting it.)
Actually the "list" interface of this library is implemented on top of cell-based feed, not list-based feed. So we cannot use the API @vkvelho mentioned, unfortunately. It is implemented in that way so that users can use cell-based API and list-based API at the same time.
Hi. I used the actual list-based feed in #100 (or #101). Couldn't we do the same here?
I hope I didn't sound rude. I'm on the road... On Jul 27, 2014 12:08 PM, "Hiroshi Ichikawa" [email protected] wrote:
Actually the "list" interface of this library is implemented on top of cell-based feed, not list-based feed. So we cannot use the API @vkvelho https://github.com/vkvelho mentioned, unfortunately. It is implemented in that way so that users can use cell-based API and list-based API at the same time.
— Reply to this email directly or view it on GitHub https://github.com/gimite/google-drive-ruby/issues/50#issuecomment-50259551 .
I need the DELETE method that actually removes the row from the spreadsheet, so I'll implement that feature in a similar way as in #100 (insert using POST). I'm not sure if that fits in this gem, but at least I can use it in forked branch.
I commented in #100 about why we don't use list-based feed. I don't want to use DELETE method of list-based method here for the same reason. I believe shifting rows has almost the same effect as deleting a row. Let me know if it isn't.
One concrete difference between shifting and deleting is that the max_rows of the worksheet is decreased by one when the row is actually deleted.
I found out that even using the DELETE request of the list-based feed isn't safe if no ETag was used. For example, you have hundreds of names in one column and the 50th row has the name you want to delete. Your app has got the edit path of that row and it's going to use DELETE request on that edit path. Now, if someone has deleted any row between 1-49, it's actually 51th row of the original worksheet that your app deletes. If an ETag was used, this didn't happen.
Any ideas how to start using ETags? I haven't looked at it yet.
One concrete difference between shifting and deleting is that the max_rows of the worksheet is decreased by one when the row is actually deleted.
Yes, it should also decrement max_rows.
Any ideas how to start using ETags? I haven't looked at it yet.
It seems you need to specify HTTP request header "GData-Version: 3.0" to get ETags, which is currently not specified. Then e.g., each entry tag in the cell-based feed has ETag:
<entry gd:etag='"ImBtWFQRQSt7"'>
Great news, @gimite. I tried that in pry as below and yes, it does return the etag for the entry.
@session.request(:get, self.list_feed_url, :header => {"GData-Version" => "3.0"})
Now I just wonder what is the version without that header and what happens if we use that header by default.
What do you think, will you make a branch that uses etags by default or what's the smart path towards the etags? Meanwhile I can make the requests with that additional header in my requests that needs etags.
Thanks.
I will make {"GData-Version" => "3.0"} as default later because older versions are deprecated. But I will make the change after the switch to Drive API is complete.