I don't appear to be getting an etag back after a delete. Is that intentional? If so, how can i make my next call appropriately after performing a delete? Do i have to rerequest the queue just to get its etag?
You delete an <item> in the queue, while the eTag is related to the queue itself. Basically the item doesn't exist after the delete so no eTag. I can see where it would be convenient to get the parent queue's updated eTag in the response, though. We'll have to think about adding this.
So will i need to get an updated etag before i proceed to make another queue modifying action? Or can i use the one i had before i did the delete? If i need to get an updated one, is there a simple way to do so without pulling down a huge queue?
Yes, you would need to requery the queue until we address this design challenge. You could request only one queue item to get the etag to get the fastest response.
Thanks! Anything you can do to eliminate excessive calls would be appreciated. Cellular networks are amazingly capricious; so minimizing communication helps out a *lot*.
Michael: I just realized that your suggestion exposes a race condition. Consider hte following sequence of calls:
From one machine an item from the queue is deleted. This causes:
a) a delete request
b) an etag request with one queue element.
Now, on another machine, between 'a' and 'b', the user does something like remove one item and add another to their queue. Because of this, the etag request will result in my client pulling down an etag for a server queue that doesn't represent the client queue. Worse yet, i cannot check the counts of the queues to see if they've changed since a 'remove then add' will leave the counts the same. So, now i'm out of sync and may potentially screw things up for the user because of it. The only safe thing to do after a delete is fully download the queue again. Needless to say, this is a *lot* of data, and takes a bunch of time over edge.
It seems to me than any queue modifying actions should always return an etag so that both the client and server can properly know what condition they're in. Would it be that tough to return this data in the response for a delete request? I dont' know enough about your internal architecture, but it doesn't seem like it should be problematic (presuming that your queues are always stamped with an etag). Would you be able to push a change like this out today/monday?
Thanks!
Unknown
–
3 years ago
Michael, i did not see any response on my email about the race condition. I'm curious why you would be unable to return an etag in this circumstance. After all, i'm posting a delete to a specific queue. So it seems like it would be fine to pass back information on how the queue was modified. I'm *not* deleting a movie (i.e. removing it from your catalog database), so it seems very odd to think of this in a movie-centric POV. Instead, i am modifying a queue in some way, and i don't see why D would need any less concurrency control than CRU.
yes, I think we are going to be adding etags on deletes on the queue soon. Michael provided an interim solution which will work for you. I should mention that the etag is actually more like a checksum hash on the queue, so any modification of the queue would make the etag matching fail. There are theoretical issues currently with concurrency between the website and the api, but honestly we have never run into any in practice.
It would seem that this is not just a problem for you. I was trying to find a way to integrate this streaming into http://harrypotterspells.net/62/list-of-harry-potter-movies-in-order/ and http://harrypotterspells.net/342/harry-potter-dvd/ but no luck. I do think Netflix should think about a way for one-off sites to run embedded content, as a single use option rather than as a subscription. I know a lot of visitors to that site end up buying single views from Amazon, and if a way existed to fulfill that through Netflix's API, that would be great.
I don't appear to be getting an etag back after a delete. Is that intentional? If so, how can i make my next call appropriately after performing a delete? Do i have to rerequest the queue just to get its etag?
Message edited by Cyrus Najmabadi 6 months ago
Michael Hart – 3 years ago
You delete an <item> in the queue, while the eTag is related to the queue itself. Basically the item doesn't exist after the delete so no eTag. I can see where it would be convenient to get the parent queue's updated eTag in the response, though. We'll have to think about adding this.
Cyrus Najmabadi – 3 years ago
So will i need to get an updated etag before i proceed to make another queue modifying action? Or can i use the one i had before i did the delete? If i need to get an updated one, is there a simple way to do so without pulling down a huge queue?
Cyrus Najmabadi – 3 years ago
Anyone have an answer on this? The rules about multiple modifications and etags are very unclear.
Michael Hart – 3 years ago
Yes, you would need to requery the queue until we address this design challenge. You could request only one queue item to get the etag to get the fastest response.
Cyrus Najmabadi – 3 years ago
Thanks! Anything you can do to eliminate excessive calls would be appreciated. Cellular networks are amazingly capricious; so minimizing communication helps out a *lot*.
Cyrus Najmabadi – 3 years ago
Michael: I just realized that your suggestion exposes a race condition. Consider hte following sequence of calls:
From one machine an item from the queue is deleted. This causes:
a) a delete request
b) an etag request with one queue element.
Now, on another machine, between 'a' and 'b', the user does something like remove one item and add another to their queue. Because of this, the etag request will result in my client pulling down an etag for a server queue that doesn't represent the client queue. Worse yet, i cannot check the counts of the queues to see if they've changed since a 'remove then add' will leave the counts the same. So, now i'm out of sync and may potentially screw things up for the user because of it. The only safe thing to do after a delete is fully download the queue again. Needless to say, this is a *lot* of data, and takes a bunch of time over edge.
It seems to me than any queue modifying actions should always return an etag so that both the client and server can properly know what condition they're in. Would it be that tough to return this data in the response for a delete request? I dont' know enough about your internal architecture, but it doesn't seem like it should be problematic (presuming that your queues are always stamped with an etag). Would you be able to push a change like this out today/monday?
Thanks!
Unknown – 3 years ago
Michael, i did not see any response on my email about the race condition. I'm curious why you would be unable to return an etag in this circumstance. After all, i'm posting a delete to a specific queue. So it seems like it would be fine to pass back information on how the queue was modified. I'm *not* deleting a movie (i.e. removing it from your catalog database), so it seems very odd to think of this in a movie-centric POV. Instead, i am modifying a queue in some way, and i don't see why D would need any less concurrency control than CRU.
mikey – 3 years ago
yes, I think we are going to be adding etags on deletes on the queue soon. Michael provided an interim solution which will work for you. I should mention that the etag is actually more like a checksum hash on the queue, so any modification of the queue would make the etag matching fail. There are theoretical issues currently with concurrency between the website and the api, but honestly we have never run into any in practice.
=-mikey-=
Cyrus Najmabadi – 3 years ago
Great! I'm glad to hear it. Thanks for acting on this guys.
ragingfury – 2 years ago
Any status on when this might be added?
Zircon Project – 11 months ago
Just wanted to bring this issue back to the forefront.
arothian – 10 months ago
Agreed, this is kinda a pain. Right now I pull back the queue again with max results of 1 after a delete operation just to get the etag.
brackem – 6 months ago
It would seem that this is not just a problem for you. I was trying to find a way to integrate this streaming into http://harrypotterspells.net/62/list-of-harry-potter-movies-in-order/ and http://harrypotterspells.net/342/harry-potter-dvd/ but no luck. I do think Netflix should think about a way for one-off sites to run embedded content, as a single use option rather than as a subscription. I know a lot of visitors to that site end up buying single views from Amazon, and if a way existed to fulfill that through Netflix's API, that would be great.