timuralp commented on this pull request.
> + * @param metadata
+ * corresponds to {@link SwiftObject#getMetadata()}.
+ * @param headers
+ * Binds the map to headers, without prefixing/escaping the header
+ * name/key.
+ *
+ * @return {@link SwiftObject#getEtag()} of the object, which is the MD5
+ * checksum of the concatenated ETag values of the {@code segments}.
+ */
+ @Deprecated
+ @Named("dynamicLargeObject:replaceManifest")
+ @PUT
+ @ResponseParser(ETagHeader.class)
+ @Headers(keys = "X-Object-Manifest", values =
"{containerName}/{objectName}/")
+ String replaceManifest(@PathParam("objectName") String objectName,
+ @BinderParam(BindToJsonPayload.class) Collection<Segment> segments,
@archupsg03 I probably was not clear on this. I was suggesting that using the
Swift PutOptions class and setting the correct header (X-Object-Manifest) would
be sufficient with the existing PutObject API. However, talking to @andrewgaul,
I understand the preference for the separate API class, as it makes the DLO
separation from the regular object API obvious.
The X-Object-Manifest header is mandatory in the API, so that header must be
set -- that is correct.
In terms of your question on behavior, for DLO, Swift's behavior depends on the
number of segments. If the number of segments is less than the full listing,
Swift computes DLO ETag as an md5 sum of segment ETags. Otherwise, the ETag is
not included. [1]
I'll try to look into the prior jclouds DLO documentation to try to understand
your question about the 1.9 implementation.
1.
https://github.com/openstack/swift/blob/master/swift/common/middleware/dlo.py#L307
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1105#discussion_r120170979
