The structure of the query is segmented in 3 different parts.
SELECT
c.id as entity_id,
We loop each field and render its associated MySQL snippet. Each MySQL snippet should bring only 1 column strictly!
FROM civicrm_contact c
{where clause}
GROUP BY c.id
The {where clause}
is getting used if we specified a contact_id
parameter during the API call.
For example, lets take the example of 'total count of contributions'. if our field's MySQL snippet, it's declared like this:
SELECT COALESCE(COUNT(t1.id), 0) FROM civicrm_contribution t1
WHERE t1.contact_id = {contact_id} AND t1.contribution_status_id = 1
AND t1.financial_type_id IN ({financial_types})
AND t1.is_test = 0
then, while preparing the final MySQL statement, query will become like this
SELECT
c.id as entity_id,
(SELECT COALESCE(COUNT(t1.id), 0) FROM civicrm_contribution t1
WHERE t1.contact_id = {contact_id}
AND t1.contribution_status_id = 1
AND t1.financial_type_id IN ({financial_types})
AND t1.is_test = 0),
FROM civicrm_contact c
{where clause}
GROUP BY c.id
Lastly, replacement of tokens take place where they will replace the placeholders {contact_id}
and {financial_types}
with their associated values.
Currently, you can debug your queries by using the parameter
By adding debug_only=1
to your call, you'll get a printout of the complete MySQL query, after the token replacement but without actually storing the query results into the table.
There are 2 destructive API call parameters at the moment that could prove useful in case you'having issues with corrupted configuration:
The main call: drush cvapi Synopsis.Maintenance operation='parameter'
.
The 'parameter':
delete_stored_config
: Will delete the stored database configuration (but not the actual CustomFields)delete_stored_customfields
: Will delete all customfields under CustomGroup called Synopsis