This pull fixes an edge case with querying a view before the view's design document is fetched via replication. Here's what my app is doing:
ddoc = [CouchDatabase designDocumentWithName:@"books"]
If I restart the app at this point, the map function is returned from CouchDesignDocument as expected. I wasn't able to figure out why the currentRevisionID of the design document wasn't updated during the replication process. My workaround was to not cache the views for a design document unless that document has a non-null _viewRevisionID.
do not cache views until the design doc is saved
This isn't the right solution. The fix has two regressions:
Well, rats. I'll go back and try to come up with a non-leaky fix.
The real issue seems to be why self.currentRevisionID is still nil after the doc gets added to the database by the replicator. The addition of the document should cause -notifyChanged: to be called, which will update the _currentRevisionID.
If you set gCouchLogLevel to 1, you'll get log messages from -notifyChanged: (**** CHANGE #...). You can use this to check whether it's being called on the design document.
**** CHANGE #...
remove previous "fix"
bug fix: replication should turn on CouchDatabase.tracksChanges in or…
…der to update replicated design docs
Got it: notifyChanged: isn't being called because _database.tracksChanges isn't being set to YES in CouchReplication.m. I've reverted the previous change and added the fix to this pull request.
I wasn't sure if tracksChanges should be turned off after replication. The CouchReplication class could potentially save the value when start is called and restore it when replication stops, but from looking at other places where tracksChanges is modified, it seems like the policy is to just leave it on.
Merge remote-tracking branch 'upstream/master' into stale_view_cache