You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just updated my projects to reference the latest library after several weeks and I found some subtle changes were need to adjust to the changed API, but nothing too troublesome.
However, one bit of my code has broken. I used to call AddContainerHeaders with key "x-versions-location" and the name of a container, or blank to remove it. This API doesn't exist any more, so what is the equivalent way of defining and removing a versions container in the latest library?
Greg
The text was updated successfully, but these errors were encountered:
Thanks for the report. I removed the method because in all the sample code I found it was only used to add/update metadata, and we already have methods for doing that. I'll add a method back to handle versioned containers prior to the 1.2.0.0 release.
While you're at it, there are a few similar cases to x-versions-location where special headers create special behaviour (x-delete-at, Log-Delivery, etc). Consider if it would be generous to wrap these "special case" headers in specific API methods to hide the implementation details from clients. Directly manipulating headers and metadata is a bit of a bother, so it would be nice to avoid them -- Greg
I just updated my projects to reference the latest library after several weeks and I found some subtle changes were need to adjust to the changed API, but nothing too troublesome.
However, one bit of my code has broken. I used to call AddContainerHeaders with key "x-versions-location" and the name of a container, or blank to remove it. This API doesn't exist any more, so what is the equivalent way of defining and removing a versions container in the latest library?
Greg
The text was updated successfully, but these errors were encountered: