On Sep 19, 2012, at 1:08 PM, Daniel Myung wrote: > My question stems around the fact that I did nothing to the design doc in > couch, but blew away the _design directory in the filesystem (*all* the > generated view files), and had to wait hours for it to regenerate only to > see the same incorrect result. > > The expected behavior of adding the newline and subsequently altering the > view to force couch to recompute the views again makes sense - that was my > fallback. Because I didn't need to "change" the view to get it to > regenerate, I thought deleting the _design directory would have the same > intended result. (because of the javascript library fix)
Ah, sorry. Misunderstood what you meant by deleting the .databasename_design folder. That does seem strange, the only thing I can think of would be to check that your current configuration is still storing the data in the expected place (or restart CouchDB in case it has a file pointer open on the deleted view data that it somehow uses to re-link it??). I would think that deleting the hidden _design folder for a database would be the ultimate form of view cleanup, but perhaps someone else could chime in with more expertise in this area. -nvw > On Wed, Sep 19, 2012 at 4:01 PM, Nathan Vander Wilt < > [email protected]> wrote: > >> On Sep 18, 2012, at 9:02 PM, Daniel Myung wrote: >> >>> Is there some type of bytecode or something cached somewhere for design >>> docs for view functions that could possibly explain how my removal of the >>> _design directory could still yield the same original result? >>> >> >> Sorry, I don't have authoritative documentation references on this, but my >> understanding is that this is how it works: >> >> 1. Removing a _design document does not remove generated views, unless you >> run view cleanup >> 2. CouchDB stores generated views on disk based on a hash of the view's >> *code* >> >> One benefit of this is that in production you can rebuild a new view e.g. >> _design/app-new while still fetching old results from _design/app, then >> switch the names once the new view has caught up. (IIRC, there may also be >> some optimization within a _design doc so identical map functions can be >> reused between different reduction functions?) >> >> Anyway, it sounds like what happened is that because your view code didn't >> actually change (just its behaviour due to JS library differences) this >> edge case meant that CouchDB assumed your view was already caught up with >> most of your database's _changes. Adding a newline to the view did change >> its "identity", and so was a reasonable way to trigger view generation. The >> other way would have been, while your _design document was temporarily >> removed, to clean up views. >> >> hth, >> -natevw >> >> >> >> >>> >>> On Mon, Sep 17, 2012 at 9:18 PM, Paul Davis <[email protected] >>> wrote: >>> >>>> I agree with Bob. This is a difference in your Spidermonkey library. >>>> >>>> On Mon, Sep 17, 2012 at 5:47 PM, Robert Newson <[email protected]> >> wrote: >>>>> I think it's to do with the version of Spidermonkey you've used, >>>>> rather than CouchDB version. >>>>> >>>>> B. >>>>> >>>>> On 17 September 2012 23:35, Cory Zue <[email protected]> wrote: >>>>>> Hi, >>>>>> >>>>>> We're in the process of migrating our app from couch 1.0 to 1.2. >>>>>> Seeing different behavior in this view function though, which is >>>>>> giving us some trouble. >>>>>> >>>>>> >>>> >> https://github.com/dimagi/core-hq/blob/master/corehq/couchapps/formtrends/views/form_time_by_user/map.js >>>>>> >>>>>> It looks like it works as designed in 1.0 but in 1.2 >>>>>> submit_time.getDay() and submit_time.getHours() both return null. >>>>>> >>>>>> Is there a better way to handle this now? >>>>>> >>>>>> Our dates are formatted like this: 2011-03-07T20:27:12Z >>>>>> >>>>>> Cory >>>> >> >>
