[MB-4549] make CAPI CRUD return $flags and $expiration in replies [was: emitting a doc into the view brings $flags and $expiration] Created: 18/Dec/11  Updated: 01/Mar/12  Resolved: 24/Jan/12

Status: Closed
Project: Couchbase Server
Component/s: ns_server
Affects Version/s: 2.0-developer-preview-3
Fix Version/s: 2.0-developer-preview-4
Security Level: Public

Type: Bug Priority: Blocker
Reporter: Matt Ingenthron Assignee: Aleksey Kondratenko
Resolution: Fixed Votes: 0
Labels: 2.0-dev-preview-4-release-notes
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
(update by alk):

As can be seen in comments we think we should always expose $flags and $expiration in json docs we expose either via CAPI CRUD or view map/reduce. So going to change CAPI CRUD code instead.

was:

(originally reported at http://www.couchbase.org/forums/thread/magic-flags-and-expiration-vars-show-view-not-doc)

i noticed that if you query a view that emits the document, you get properties like $flag and $expiration, but if you query the http interface for the document url itself, it only shows _rev and _id, not any of the dollar sign magic variables. is there a reason behind that difference?
curl "http://192.168.96.128:8092/default/_design/test/_view/all?key=%22test%2Fquery-1324052106.5247-11152826%22"
{"total_rows":39,"rows":[
{"id":"test/query-1324052106.5247-11152826","key":"test/query-1324052106.5247-11152826","value":{"_id":"test/query-1324052106.5247-11152826","_rev":"1-00009fddf9213ed70000000d00000000","$flags":0,"$expiration":1324055706,"foo":"bar"}}
]}
curl "http://192.168.96.128:8092/default/test%2Fquery-1324052106.5247-11152826"
{"_id":"test/query-1324052106.5247-11152826","_rev":"1-00009fddf9213ed70000000d00000000","foo":"bar"}

 Comments   
Comment by Aleksey Kondratenko [ 19/Dec/11 ]
Matt, do you think we should instead fix CAPI CRUD to add those fields? It feels more natural, because otherwise this information is not available via couch API.
Comment by Matt Ingenthron [ 19/Dec/11 ]
That was the other thing I'd considered, yeah. I do agree that it makes more sense to have it there too (and actually, I thought it was!) so long as it won't break anything else.
Comment by Steve Yen [ 24/Jan/12 ]
alk thinks this might be fixed already / raising to Blocker status on his request, so it appears at the top of his list
Comment by Aleksey Kondratenko [ 24/Jan/12 ]
double checked
Generated at Wed Oct 22 18:25:13 CDT 2014 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.