possible bug querying a GridFS Document with an updated meta-data

[ashishgidh]

Not sure if this maybe a bug. I Inserted a GridFS document with some metadata. The GET APIs work fine for all or individual documents. But when I update the metadata of the document to a different value, it always retrieves the values from the first version of the document but not the latest. This does not show when you retrieve all the documents from a collection in a GridFS, but only if you retrieve one document passing an ID. I did not see this behavior in any other normal collection.

Thanks in advance.

[mkjsix]

Could you please write us in details what are you doing, so that we can reproduce the same behavior?For example, when you say you update the metadata what operations are you performing?

[ashishgidh]

Hello,

Thanks for your attention.

This was a simple test where I posted an XML to the GridFS collection called raw.files and passed in some optional metadata. properties={"source":"STATSTEST", "sourcepath":"/sourcein/data/example","filename":"testfilename"}

When you first GET API the document like below http://localhost:8080/sportsdatahub/raw.files/562e45edfb111501ceb5de79 The above properties are retrieved correctly.

Now I update the source value above to "STATSTESChanged" as an example. I did this via a robomongo. When I now query it still returns back the previous properties. Not the changed.

I did not see this in any other collection but only the GridFS collection (example : raw.files)

Thanks, Ashish Gidh

On Mon, Oct 26, 2015 at 12:26 PM, Maurizio Turatti <notifications@github.com

wrote:

Could you please write us in details what are you doing, so that we can reproduce the same behavior?For example, when you say you update the metadata what operations are you performing?

— Reply to this email directly or view it on GitHub https://github.com/SoftInstigate/restheart/issues/60#issuecomment-151196556 .

[mkjsix]

Thanks, as the behavior should be the same as per other kind of collections it sounds like a bug. We'll investigate the issue and let you know asap.

[ashishgidh]

Hi Maurizio,

Just curious to see if you had experienced or investigated the above.

Thanks Ashish

[ujibang]

Hi,

the file properties cannot be updated yet. If you try you'll get 501 Not Implemented, as you can see below

note the file metadata property update is already on the roadmap: https://softinstigate.atlassian.net/browse/RH-64

$ http -a a:a -f PUT 127.0.0.1:8080/test/checksize.files/5639d073c2e66af9dfe64178 file@~/Desktop/web\ stuff.xcf a="new property"

HTTP/1.1 501 Not Implemented
...

{
    "http status code": 501, 
    "http status description": "Not Implemented", 
    "message": "file resource update is not yet implemented",
    ...
}

[ashishgidh]

Just to clarify. We were only trying to retrieve the information via the GET after updating the property in the back end via a mongo client.

If you retrieve all the documents without passing the ID you get the corrected updated property. But not when you try to retrieve the individual document passing in the ID.

We were not trying to update the property with the API call. Just to clarify again.

[ujibang]

If the document is updated by a different mongo client without changing the _etag property (with a new ObjectId), an http client such a browser will issue the GET request with the If-No-Match request header specifying the old ETag.

In this case RESTHeart checks it against the stored _etag property and, in case they match, it returns 304 Not Modified.

This is the ETag web caching as mandated by the http protocol. You'll find more info in the ETag documentation section.

So I suspect that this is not a bug, but just your client showing the old data due to web caching.

Note that RESTHeart is stateless, it does not cache documents on its own.

Try to have your mongo client to update the _etag property with something like:

{
  _id: "the document id", 
   prop1: 1,
   prop2: 2,
   _etag: new ObjectId()
}