You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Andrew Melo <an...@gmail.com> on 2012/08/12 00:11:25 UTC
Strange caching
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.
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
Re: Strange caching
Posted by Andrew Melo <an...@gmail.com>.
On Sat, Aug 11, 2012 at 6:55 PM, Robert Newson <rn...@apache.org> wrote:
>
> If you had declared complete_job *inside* your map function, rather than before, this wouldn't happen. i.e,
>
> function(doc) {
> function complete_job(doc) {
> }
>
> }
>
> It's regrettable that your map string works as-is. Future versions of couchdb will insist on proper encapsulation (this is forced on us by spidermonkeys removal of anonymous functions anyway).
Ah, I wasn't aware that was the recommendation. It certainly had me
really confused :)
Thanks for the help,
Andrew
>
> B.
>
> On 12 Aug 2012, at 00:36, Andrew Melo wrote:
>
>> 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 <an...@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 <an...@gmail.com> wrote:
>>>> On Sat, Aug 11, 2012 at 5:52 PM, Robert Newson <rn...@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 <an...@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
>
--
--
Andrew Melo
Re: Strange caching
Posted by Robert Newson <rn...@apache.org>.
If you had declared complete_job *inside* your map function, rather than before, this wouldn't happen. i.e,
function(doc) {
function complete_job(doc) {
}
}
It's regrettable that your map string works as-is. Future versions of couchdb will insist on proper encapsulation (this is forced on us by spidermonkeys removal of anonymous functions anyway).
B.
On 12 Aug 2012, at 00:36, Andrew Melo wrote:
> 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 <an...@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 <an...@gmail.com> wrote:
>>> On Sat, Aug 11, 2012 at 5:52 PM, Robert Newson <rn...@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 <an...@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
Re: Strange caching
Posted by Andrew Melo <an...@gmail.com>.
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 <an...@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 <an...@gmail.com> wrote:
>> On Sat, Aug 11, 2012 at 5:52 PM, Robert Newson <rn...@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 <an...@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
Re: Strange caching
Posted by Andrew Melo <an...@gmail.com>.
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 <an...@gmail.com> wrote:
> On Sat, Aug 11, 2012 at 5:52 PM, Robert Newson <rn...@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 <an...@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
Re: Strange caching
Posted by Andrew Melo <an...@gmail.com>.
On Sat, Aug 11, 2012 at 5:52 PM, Robert Newson <rn...@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 <an...@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
Re: Strange caching
Posted by Robert Newson <rn...@apache.org>.
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.
B.
On 11 Aug 2012, at 23:18, Andrew Melo wrote:
> On Sat, Aug 11, 2012 at 5:11 PM, Andrew Melo <an...@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
Re: Strange caching
Posted by Andrew Melo <an...@gmail.com>.
On Sat, Aug 11, 2012 at 5:11 PM, Andrew Melo <an...@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