pyrax icon indicating copy to clipboard operation
pyrax copied to clipboard

get_object_metadata fails to pull default metadata

Open meferguson84 opened this issue 11 years ago • 4 comments

First time using GitHub so I apologize if I don't provide the necessary information.

When creating an object, the default headers "content-length", "bytes", "etag", "x-timestamp", "x-trans-id", "date", and "last-modified" are automatically affixed to the object. However, because get_object_metadata() only pulls metadata that has the prefix "x-object-meta-" it is failing to pull these default headers. If I add metadata manually using set_object_metadata, the proper "x-object-meta-" prefix is affixed and these headers are returned.

As a side note, when using fetch_object(include_meta=True), all metadata is returned since it does not check for a prefix. Is this intended functionality or is this a bug in the way Pyrax creates objects?

This should be easily reproducible by creating a new object in a test container and then calling get_object_metadata on that object. It should return an empty dictionary.

Thanks for your time and attention. Please let me know if I can provide more information.

meferguson84 avatar Feb 13 '14 20:02 meferguson84

The 'default headers' you mention are returned as attributes on the object itself in pyrax. IOW, if you call obj = container.get_object("foo"), you can then access foo.bytes to get its size, or foo.etag to get its hash.

Since fetch_object() returns just the bytes for the object, the include_meta option gives you all of the metadata, since you aren't getting the StorageObject instance with that information as attributes. It might seem confusing, but those are two very different use cases.

EdLeafe avatar Feb 13 '14 20:02 EdLeafe

Understood. So once I assign an object, I can pull obj.last_modified or other tags to view those attributes. Thanks. That was a little unintuitive for someone new to Pyrax (and Python for that matter). Much appreciated!

meferguson84 avatar Feb 13 '14 21:02 meferguson84

That's excellent feedback. Did you find the docs confusing or misleading? I'm always looking to improve them.

EdLeafe avatar Feb 13 '14 21:02 EdLeafe

I would say yes. I was using cloud_files.md. The doc is very, very helpful, but I couldn't find any mention of what you described here. In one paragraph it states that new metadata is always appended with the "x-object-meta-" prefix (or "x-container-meta-" or what have you), but then in the example where it pulls object meta data (using a tuple with obj.fetch) none of the data has that prefix. I couldn't for the life of me figure out why I could see it using obj.fetch but not cf.get_object_metadata. I even stepped through the code which is where I discovered all meta data was being compared and only that with the specified prefix was being returned. I assumed it was a bug in the way those default attributes were assigned as metadata, but now I understand.

That's a lot of words, but I guess what I'm trying to say is in the section titled "Metadata for Containers and Objects" or perhaps "Retrieving (Downloading) Stored Objects" it could be mentioned that the default object attributes can be accessed using obj.attribute. I'm sure someone more advanced with Python than I would figure that out during debugging, but it was tough for me.

Hopefully that makes sense.

meferguson84 avatar Feb 13 '14 21:02 meferguson84