iOS-Couchbase - Views do not update/refresh

[JP Fiset]

I have just deployed a new iOS-Couchbase application on my iPad and have noticed that the views, once queried, do not update according to the changes in the database. It is as if the view was not refreshed after a document creation/update.

I have simplified the problem to the point that I can exhibit this problem with the simplest view:

function(doc) {

   emit(doc._id,null);

}

When this view is first called, the appropriate information is returned (list of document ids). This is pretty much the same as db/_all_docs.

However, subsequent calls to the same view continue to show the same result, even though changes took place in the database.

Loading this into the iOS Simulator, I notice the following behaviour:

1. The first time that the view is requested, a log line is reported in the XCode debugger window:

>1 [info] [<0.709.0>] 127.0.0.1 - - GET /demo/_design/mobile/_view/identity?onlyRows=true 200 

At that point, the result is correct.

2. After creating a new document, the view is called again. The reported debug line is:

>1 [info] [<0.1013.0>] 127.0.0.1 - - GET /demo/_design/mobile/_view/identity?onlyRows=true 304

Yet, the view needs to be update and new results should be reported. If calling _all_docs, then the HTTP code is 200 and the right results are returned.

Here are my questions:

1. Is this a known bug?

2. Is there a way to prompt CouchDb to refresh its views?

3. What component is returning the 304 and where should I file this bug?

4. Are there a INI settings to influence the behaviour of view indexing? 

Thanks,

JP 

[Jens Alfke]

On Aug 17, 2011, at 9:42 AM, JP Fiset wrote:

I have just deployed a new iOS-Couchbase application on my iPad and have noticed that the views, once queried, do not update according to the changes in the database. It is as if the view was not refreshed after a document creation/update.

Yikes. I haven’t confirmed, but it’s possible we’ve overlooked this since our simple demo app doesn’t use views, and we haven’t implemented much in the way of tests in the iOS project yet. (That is nearing the top of our to-do list, though, since Farshid just set up an automated build system for iOS-Couchbase.)

I’ll make sure we look into this today. I don’t personally know enough about the innards of CouchDB to diagnose it, but I’ll definitely add a unit test to EmptyApp to reproduce the issue.

(My suspicion is that this comes from the specific snapshot of CouchDB that we’ve merged in. I think I remember a brief regression like this being reported on the user@couchdb mailing list last month.)

—Jens

[Aaron Miller]

Not sure what onlyRows is supposed to do, but i'm not having the
problem on my end with the same view. Mind, I'm testing with curl
right now. If the problem does happen when using CouchCocoa or some
other client, it may have something to do with one of the caching
headers.

[Jens Alfke]

On Aug 17, 2011, at 10:29 AM, Aaron Miller wrote:

Not sure what onlyRows is supposed to do, but i'm not having the
problem on my end with the same view.

I’m not getting the problem either. I’ve added a new unit test to EmptyAppTests. What I see is that, after adding a document to the db, the ETag header in the response from the view changes, as expected.

If the problem does happen when using CouchCocoa or some
other client, it may have something to do with one of the caching
headers.

I don’t think so. The server is logging that it sent a response, with a 304 status, so that shows that the client didn’t intercept the request and return cached data.

JP: What build of Couchbase.framework are you using?

—Jens

[Aaron Miller]

If a client sends an ETag header to couch with a GET and couch determines the view has not changed since that ETag, couch sends back a 304 and no data (which tells the client to retrieve it from cache), since it is expected that any client that sends ETags has a cache at -least- of the ETag it is sending.

[JP Fiset]

The Couchbase.framework appears to be dated from 2011-08-12

The onlyRows parameter is my mistake and was removed.

After restarting, the identity view returned HTTP 200, but with stale information. Subsequent calls return HTTP 304.

[Jens Alfke]

On Aug 17, 2011, at 10:39 AM, Aaron Miller wrote:

If a client sends an ETag header to couch with a GET and couch determines the view has not changed since that ETag, couch sends back a 304 and no data (which tells the client to retrieve it from cache), since it is expected that any client that sends ETags has a cache at -least- of the ETag it is sending.

Yes; but in this case the view _did_ change since the last GET, so its ETag is now different, and nothing the client sends should be able to result in a 304 since the client can’t possibly guess the new ETag.

Unless … JP, what is the exact request the client is sending, including headers? If it’s using If-Modified-Since instead of If-None-Match, then it could get a false 304 back, since the Last-Modified date is only accurate to within a second.

—Jens

[JP Fiset]

Since the application is within phoneGap, I do not seem to be able to enable the WebKit debugger. Is there a way, from the CouchDb server side, to log all the requests that it receives? Since CouchDb logs to the XCode debug console, it might be easier for me to catch those issues there.

[Jens Alfke]

On Aug 17, 2011, at 10:36 AM, I wrote:

I’m not getting the problem either. I’ve added a new unit test to EmptyAppTests. What I see is that, after adding a document to the db, the ETag header in the response from the view changes, as expected.

FYI, here’s the unit test:

http://review.couchbase.org/#patch,sidebyside,9057,1,EmptyApp/Tests/EmptyAppTests.m

—Jens

[JP Fiset]

The ajax call that perform the view query is performed via jQuery. I changed the call so that caching is turned off. As a result, modified headers are not supposed to be sent (not verified on iPad, but OK on other platforms). As well, the calls are augmented with "_=[TS]", which does not seem to bother CouchDb.

As a result, all view request now return HTTP 200. However, stale information is still sent.

This is very puzzling since you do not see this issue.

[JP Fiset]

Jens,

I have reviewed your test cases and they seem appropriate. I do not have a way to see the headers flying between CouchDb and the app, so I do not know the state of the ETag. Nevertheless, the content of the response does not match what I am expecting to see.

My application uses replication to load the initial objects. I will create a simpler test, yet, to see if I can catch it earlier in the process.

[JP Fiset]

I finished writing a test case, in javascript, that perform the following activities:

- authenticate

- creates a database

- create a known document

- verifies identity view

- create a second known document

- verifies that identity view is updated correctly

Using this simple test case, the views appear to refresh/update correctly. I am currently stomped as to why my other application is not working. However, the other application is more complex, contains multiple views and involves replication. I'll continue augmenting my test case with those components to see what causes the views to mis-behave.

Sorry for taking your time on this matter. I'll continue investigating and if something worthwhile is coming up, I'll inform you.

Thanks or your help.

[J Chris Anderson]

On Thu, Aug 18, 2011 at 6:41 AM, JP Fiset <jpf...@gmail.com> wrote:

Using this simple test case, the views appear to refresh/update correctly. I am currently stomped as to why my other application is not working. However, the other application is more complex, contains multiple views and involves replication. I'll continue augmenting my test case with those components to see what causes the views to mis-behave.

Sorry for taking your time on this matter. I'll continue investigating and if something worthwhile is coming up, I'll inform you.

Thank you for investigating seriously. I will be surprised if you dont' find ANY bugs we need to fix. Hopefully the outcome of this adventure is that you learn a lot about Couch and we find someone worth fixing that we wouldn't have found without you.

Chris

Thanks,

Chris

[JP Fiset]

The headers from client requests are sent to the debug console if couchdb is configured to log at level 'debug'. One needs to set the following lines to the couchbase INI file:

[log]

level = debug

[JP Fiset]

I tracked down this issue with views that are not updated when the saved object contains a large integer. In my bigger test case, I was saving the timestamp with each object. Since the javascript timestamp is a large integer, the document saved looked like:

{

  "name": "my name"

  ,"ts": 1313684610751

}

When this object is submitted, it is accepted as is. Retrieving the object also works fine. However, views are not updated with this new object. On the server console, no error is returned.

When querying the identity view for the first time, a message indicating that a document is processed is sent at the debug console:

1> [debug] [<0.81.0>] New task status for testdb _design/test: Processed 1 of 1 changes (100%)

1> [debug] [<0.81.0>] New task status for testdb _design/test: Finishing.

However, the identity view returns the same content as was returned before adding the new document. 

A slightly different test yields a different result. In fact, the following document is indexed fine:

{

  "name": "my name"

  ,"ts": 1313

}

It appears to me that there is a component in the iOS-Couchbase that can not handle large numeric form. I'll investigate further.

If someone can verify my results, I would greatly appreciate.