Boto: S3: set_metadata does not set metadata remotely in the simplest case.

Created on 20 Sep 2012  Â·  6Comments  Â·  Source: boto/boto

S3: set_metadata doesn't actually update metadata unless you call one of the set_contents_from_* command.

It will keep it in the key that you have in memory, but if you restart python and get that key again, it won't have that metadata.

No Action Taken s3

Most helpful comment

I agree that you can do that but I don't think you should do that every time someone changes a value in the local object, do you?

It would be nice, however, to have a save() method that does this on-demand, as with most ORMs. Right now, the lack of something like this or a disclaimer in the docs makes it _seem_ like calling set_metadata() will, well, set the metadata on s3. This is particularly non-obvious because of the perceived symmetry between the various set_* methods.

I guess some additional documentation would be an easier solution, although save() would be rather convenient as a user. :)

All 6 comments

Metadata can only be set at the time the object is written to S3 or when it is copied. There really isn't anything boto can do about this.

Hi Mitch,

I don't think that's correct. You can do copy-in-the-cloud from an object to itself, specifying x-amz-copy-source to point to the origin object and x-amz-metadata-directive:REPLACE, and then setting headers (which has the effect of just updating the metadata/headers). For example, running the following command:

gsutil -d setmeta -h Content-Type:text/html s3://mfsbucket/abc

here's the HTTP that's sent:

send: 'PUT /mfsbucket/abc HTTP/1.1\r\nHost: s3.amazonaws.com\r\nAccept-Encoding: identity\r\nContent-Length: 0\r\nx-amz-storage-class: STANDARD\r\nUser-Agent: Boto/2.6.0-dev (darwin) gsutil/3.19_PRE (darwin)\r\nx-amz-copy-source: mfsbucket/abc\r\nDate: Wed, 14 Nov 2012 22:05:27 GMT\r\ncontent-type: text/html\r\nAuthorization: ....=\r\nx-amz-metadata-directive: REPLACE\r\n\r\n'

And after running the command, I verified that the Content-Type was indeed updated.

(I implemented this command for Google Cloud Storage, but it works for S3 as well.)

Mike

I agree that you can do that but I don't think you should do that every time someone changes a value in the local object, do you?

Oh, sorry, I didn't realize the context here - acrefoot@ was asking about
setting metadata in the in-memory object, and expecting that it would sync
through to the storage service. I agree, you don't want to do that every
time someone changes a value in the local object.

Mike

On Wed, Nov 14, 2012 at 3:17 PM, Mitch Garnaat [email protected]:

I agree that you can do that but I don't think you should do that every
time someone changes a value in the local object, do you?

—
Reply to this email directly or view it on GitHubhttps://github.com/boto/boto/issues/1007#issuecomment-10388313.

I agree that you can do that but I don't think you should do that every time someone changes a value in the local object, do you?

It would be nice, however, to have a save() method that does this on-demand, as with most ORMs. Right now, the lack of something like this or a disclaimer in the docs makes it _seem_ like calling set_metadata() will, well, set the metadata on s3. This is particularly non-obvious because of the perceived symmetry between the various set_* methods.

I guess some additional documentation would be an easier solution, although save() would be rather convenient as a user. :)

+1 to @xiongchiamiov

Was this page helpful?
0 / 5 - 0 ratings