CiviCRM Community Forums (archive)

Not that we don't care about it, but it hasn't make it near the top enough to get it implemented properly.

I'm not sure there is a simple and easy way to make it generic, but if you could find a way of having a _civicrm_api3_basic_getcount like there is a  _civicrm_api3_basic_get

then having a generic getCount isn't far away (under api/v3/Generic)

Haven't looked at what DAO offers, but definitely would be a better implementation. Would be great if you could have a look

X+

The API is somewhat different from the rest of the code as we don't control the consumer side and it might be better to let them use the right getcount api that is badly implemented than having them calling get and do the count, as when we fix it, it's automatically fixed everywhere.

For the contact.getcount, this code (from api v2, should/might do the trick?)

   
function civicrm_api3_contact_getcount($param){
    require_once 'CRM/Contact/Form/Search.php';
    $newP = CRM_Contact_BAO_Query::convertFormValues( $params );
    $query = new CRM_Contact_BAO_Query( $newP );
    return array ('count'=>$query->searchQuery( 0, 0, null, true ));
//here, probably one of the few cases where we don't use civicrm_api3_create_success as we don't want a values array, just count, to be checked

}


We'd like to welcome you to the API Team - but first you have to pass the stringent entry criteria - you have to tell a bad joke

For reference, my patch doesn't fix all getCount implementations. As per xavier's helpful notes, getCount is implemented with a 'generic' function (i.e. it's used as a fallback if an entity doesn't implement it specifically). The current implementation just calls get and then counts the result. What my patch does is add an extra parameter "getCount" = TRUE before doing that call, and then if the result is a scalar instead of an array, assumes the entity is implementing the new getCount parameter and returns that instead of the count.

For the contact implementation, I dug into the dao object and saw that when the sql is generated by the query method, there's an optional first argument 'count' which if set to TRUE will generate the sql I want, so it made sense to use that. I only found one other case of code actually using this count parameter, but I'm crossing my fingers that it should work as advertised and it did in my various tests. So the rest of the patch (CRM/Contact/BAO/Query.php and api/v3/Contact.php) are really just adding the extra parameter and passing it down.

My hope is that any other implementations of getCount would be fairly straightforward and can be done as needed now.

You might have thought that I should follow the pattern set up in the api and implement the getCount for each entity, but that would mean copying a lot of the same stuff in the get implementation, so I opted for a more surgical approach ...

I've added patches to the issue for both 3.4 and trunk/4.2. The trunk/4.2 patch works on 4.1 with minimal cleanup, I'll post a clean 4.1 patch if anyone requests.

Hi,

The 'normal' way to have a specific behaviour for an entity that is different than the generic is to simply add it (in api/v3/Contact.php)

function civicrm_api3_contact_getCount($params) {
   return civicrm_api3_contact_get($params,true);
}

by doing it that way it makes it clearer what entities have been fixed already.

and instead of adding a getCount in the param, I'd change the signature
function civicrm_api3_contact_get($params,$countOnly=false) {
}

Otherwise on api v2, search_count was using
    return $query->searchQuery( 0, 0, null, true );

but I think what you did by modifying the apiQuery is safer (more change to get the same result).

Make sense? Could you alter your patch?