Occurance count() vs search()['count']

[faroit]

I get an explainable behavior when I'm calling the occurances.count() using a list of dataKey.

• lets count occurances on one dataset1

occ.count(taxonKey=3190653, datasetKey=['7a3679ef-5582-4aaa-81f0-8c2545cafc81'])
>> 988

• lets do the same for another dataset

occ.count(taxonKey=3190653, datasetKey=['50c9509d-22c7-4a22-a47d-8c48425ef4a7'])
>> 12709

• Now, I would expect that using both keys will get me 988 + 12709, but instead returns

occ.count(taxonKey=3190653, datasetKey=['7a3679ef-5582-4aaa-81f0-8c2545cafc81', '50c9509d-22c7-4a22-a47d-8c48425ef4a7'])
>> 988

• When I use the occurance search to get the count

occ.search(taxonKey=3190653, datasetKey=['7a3679ef-5582-4aaa-81f0-8c2545cafc81', '50c9509d-22c7-4a22-a47d-8c48425ef4a7'], limit=0)['count']
>> 13697

the result seems to be as expected. Is this a bug or is there any other reason for the different behaviors?

[sckott]

I think count and search work slightly differently. count only allows one value per query while search allows more than 1. I can document that better.

for count i guess a list comprehension or similar would work

[faroit]

I think count and search work slightly differently. count only allows one value per query while search allows more than 1. I can document that better.

great! that helps!

for count i guess a list comprehension or similar would work

sure, but is there any reason to prefer the count api over search()['count'] then?

[sckott]

At one point a few years back they said they would deprecate the occurrence/count route https://dev.gbif.org/issues/browse/POR-3173/ but it is still around.

there may be a time penalty for using search instead of count, I don't know. search seems better since you can do multiple dataset keys

[faroit]

Right. Thanks a lot. I guess this can be addressed with updated docs. I can review a PR of that helps.