incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Melo <andrew.m...@gmail.com>
Subject Re: Strange caching
Date Sat, 11 Aug 2012 23:36:57 GMT
Oh MAN, I just figured it out. This is bizarre.

So, there's another view, which also has a helper function called
complete_job. I didn't change the other view's complete_job to also
look for 'failed'. Somehow, that function leaked into the other map
function and was being called. Changing the map in view2 fixed view1,
for whatever reason.

That seems like really strange behavior, right?

Thanks,
Andrew

On Sat, Aug 11, 2012 at 6:06 PM, Andrew Melo <andrew.melo@gmail.com> wrote:
> Playing around with things a bit more, I replicated my local database
> to my cloudant instance and got the same behavior, and making a new
> design document where I copy-paste the map code yields a view that
> returns the right value. I'm not sure what that means. There wouldn't
> be some couchapp-specific magic that would cause some docs to not be
> applied to the map, would there?
>
> On Sat, Aug 11, 2012 at 5:56 PM, Andrew Melo <andrew.melo@gmail.com> wrote:
>> On Sat, Aug 11, 2012 at 5:52 PM, Robert Newson <rnewson@apache.org> wrote:
>>>
>>> By chance are you using an editor like emacs that makes foo~ style backup files?
I found that couchapp would find the ~ backup file and not the latest version.
>>
>> No, I'm using eclipse and I verified that the design document stored
>> in the DB has "the right" view.
>>
>> Thanks!
>> Andrew
>>
>>>
>>> B.
>>>
>>> On 11 Aug 2012, at 23:18, Andrew Melo wrote:
>>>
>>>> On Sat, Aug 11, 2012 at 5:11 PM, Andrew Melo <andrew.melo@gmail.com>
wrote:
>>>>> Hey all,
>>>>>
>>>>> I'm at my wits end here trying to figure this out, maybe someone can
help.
>>>>>
>>>>> I have a view with a map function and a database with one document.
>>>>> The view just looks for if doc['state'] is 'failed' or 'done' and if
>>>>> there is, it emits a value. A previous version of the view only
>>>>> checked for 'done'. If it helps, I'm running these tests in a unittest
>>>>> which deletes the database after every test case, and i've also
>>>>> manually deleted the database from futon to be extra-sure that it's
>>>>> gone and any state's been blown away.
>>>>>
>>>>> Now, if my document has state = done, the view correctly shows the one
>>>>> row. However, if state = false, the view emits zero rows. I've added
>>>>> some log() statements into the branch that should be executed if the
>>>>> doc fails the state test, and it's not executed. It seems like somehow
>>>>> an old old version of the view has been cached somewhere. Stranger,
>>>>> the docs contain timestamps, so the hashes should be different in
>>>>> every invocation, so if my understanding of how the view caching
>>>>> works, this shouldn't be cached at all.
>>>>>
>>>>> Strangely, if I go to futon, select the offending view, hit the "view
>>>>> code" function and insert whitespace, it returns the correct value.
>>>>>
>>>>> Is there some strange bug I'm triggering or is this a known feature?
>>>>> I've pasted my view and my doc below.
>>>>
>>>> I guess I should add that this is part of a couchapp, I'm running the
>>>> CouchBase OSX binaries and this is replicatable across invocations
>>>> (i.e. delete the database, shutdown server, restart server, run test)
>>>>
>>>>>
>>>>> Thanks in advance,
>>>>> Andrew
>>>>>
>>>>> my view:
>>>>> function complete_job(doc) {
>>>>>        if ( (doc['state'] == 'failed' )  || ( doc['state'] == 'done'
) ) {
>>>>>                return true;
>>>>>        }
>>>>>        log( doc );
>>>>>        log(doc['state']);
>>>>>        return false;
>>>>>
>>>>> }
>>>>> function(doc) {
>>>>>        if(doc.lfn && complete_job(doc)){
>>>>>                emit(doc.last_update, {"lfn": doc.lfn, "workflow": doc.workflow,
>>>>> "location": doc.destination, "checksum": doc.checksums, "jobid":
>>>>> doc.jobid, "retry_count": doc.retry_count.length+1, "size": doc.size,
>>>>> "state" : doc.state});
>>>>>        }
>>>>> }
>>>>>
>>>>> My document:
>>>>> {
>>>>>   "_id": "e5c47962375981dd336c2bc8d4a94208375935f06868847f3363daaa",
>>>>>   "_rev": "2-7a50be4c10264ab4fb94a5bbf489dcfc",
>>>>>   "inputdataset": "",
>>>>>   "lfn": "/store/user/meloam/T2stop_600_50_0_5test/MeloAcquisitionEra/IntegrationTest_120810/00000/B4749FB5-38E3-E111-ADC3-782BCB4FBD6F.root",
>>>>>   "checksums": {
>>>>>       "adler32": "5759a594",
>>>>>       "cksum": "468777326"
>>>>>   },
>>>>>   "size": 2432988,
>>>>>   "group": "",
>>>>>   "destination": "T1_US_FNAL_Buffer",
>>>>>   "last_update": 1344722369,
>>>>>   "source": "T2_US_Vanderbilt",
>>>>>   "state": "failed",
>>>>>   "role": "",
>>>>>   "dbSource_url": "http://127.0.0.1:5984",
>>>>>   "dn": "None",
>>>>>   "workflow": "meloam_ASYNCTEST1_120810_170823_8981",
>>>>>   "timestamp": 1344722369,
>>>>>   "start_time": "2012-08-11 16:59:29.754080",
>>>>>   "job_end_time": 1342768166,
>>>>>   "dbs_url": null,
>>>>>   "publication_retry_count": [
>>>>>   ],
>>>>>   "user": "T2stop_600_50_0_5test",
>>>>>   "dbSource_update": 1342768166,
>>>>>   "publication_state": "not_published",
>>>>>   "task": "/meloam_MeloMCGenTestv6_120719_204741_1342/Production",
>>>>>   "jobid": "a9a04888-d239-11e1-b31b-001d7d020436-0",
>>>>>   "retry_count": [
>>>>>       "2012-08-11 16:59:29.963710"
>>>>>   ],
>>>>>   "publish_dbs_url": "",
>>>>>   "end_time": "2012-08-11 16:59:29.963710"
>>>>> }
>>>>>
>>>>> --
>>>>> --
>>>>> Andrew Melo
>>>>
>>>>
>>>>
>>>> --
>>>> --
>>>> Andrew Melo
>>>
>>
>>
>>
>> --
>> --
>> Andrew Melo
>
>
>
> --
> --
> Andrew Melo



-- 
--
Andrew Melo

Mime
View raw message