Details
-
Type:
Bug
-
Status: Done/Fixed
-
Priority:
Major
-
Resolution: Won't Fix
-
Affects Version/s: 4.5
-
Fix Version/s: 4.5
-
Component/s: Core CiviCRM
-
Labels:None
-
Documentation Required?:None
Description
group_contact_cache table is being truncated and NOT rebuilt on edit of contact name.
To recreate:
- create a smart group w/ N members and view in Manage Groups selector (you'll see the count)
- In a separate tab, go to a contact summary for some contact and use inline edit to update the contact name
- reload Manage Groups tab - the count will be set to 0 (the group_contact_cache table is empty
The process which is truncating the cache based on a contact record update SHOULD be rebuilding it - but that's not happening for some reason w/ this flow.
NOTE: If you try the steps again before the cache times out - the bug doesn't repeat. You have to wait for the cache timeout period to recreate again.
Attachments
Activity
I would think the correct behavior would be to do nothing to the group_contact_cache when editing a contact. It's too expensive to rebuild it every time, and truncating it is not helpful either.
Reason for rebuilding cache is to ensure smart groups are built correctly. For eg, if I have a smart group of contacts with state "California" and then after I update few contact to another state those contacts should be removed from the smart group.
I understand that the smart group cache may get stale, but isn't that the point of the timeout setting and the cron job which rebuilds them?
What's the purpose of those things if we clobber the cache on every single contact edit? On a busy site civicrm contacts might be edited once or more per second. And on a site with lots of smart groups and contacts the rebuild might take 30 seconds or more... do we really want inline editing to take 30 seconds to complete because of this?
Kurund - assigning to you since we don't know if this actually is a bug. Please assign on to Coleman to minimally correct the usability issue with '0' count being displayed on manage groups (assuming we leave everything else alone).
Looking at this bug, it seems to be more about the way the "Count" column is calculated than a real issue with whether or not the cache should be rebuilt.
On our site I have completely disabled group contact caching because the query to remove stale groups was taking so long (10 to 15 minutes to execute) it was choking our database and causing massive usability issues. I haven't seen any serious performance issues from the disabling of the caching - the performance issues were caused by the operation of the caching.
This is expected behavior. Cache is rebuilt as needed.
I think that this is an efficient way of managing a cache. This is a workaround but IMO shouldn't be needed:
https://github.com/civicrm/civicrm-core/pull/3906
I've assuming from the ticket that this is a 4.5 regression - not a bug present in previous versions?