Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I have a site where this module is used on every node creation and users create a few nodes every day. The table cache_entityconnect is growing fast and is becoming really big because their entries are never cleaned.
Comment | File | Size | Author |
---|---|---|---|
#2 | entityconnect-clear_cache-2608188-1.diff | 816 bytes | camilo.mejia |
Comments
Comment #2
camilo.mejia CreditAttribution: camilo.mejia commented- Changed parameter CACHE_PERMANENT to REQUEST_TIME + 21600 on cache_set
- Added hook_flush_caches
Comment #3
steinmb CreditAttribution: steinmb as a volunteer commentedI' currently reviewing this module. What about having the time configurable? Define the time in variable and if it is not set, never expire? You did not say anything about the size of the site you see this on and the size of the cache table. Care to touch on that?
Comment #5
jygastaud CreditAttribution: jygastaud commentedThanks @camilo.mejia for the patch.
hook_flush_caches is a nice catch. I forgot it.
I also agree with @steinmb. It would be perfect to add an option into the administration to be able to fix the cache lifetime and default to CACHE_PERMANENT if nothing is set.
So, I just push that option inside 7.x-1.x branch.
I mark that issue as fixed.
If something wrong happen, please reopen it.
Thanks.
Comment #7
steinmb CreditAttribution: steinmb as a volunteer commented@jygastaud thank you :)
Comment #8
camilo.mejia CreditAttribution: camilo.mejia commentedI choose 21600 because is the same time Drupal core use to cache their forms: https://api.drupal.org/api/drupal/includes%21form.inc/function/form_set_.... I think a configurable parameter is not necessary because this cache could exist at least the same time that the cached core forms.
For Drupal 8, instead of a configurable parameter, you could use variable_get('cache_form_expiry', 21600); or whatever the core team decide to use when they finish this: https://www.drupal.org/node/2091511
Comment #9
aharris6 CreditAttribution: aharris6 commentedThank you for this patch, @camilo.mejia and @jygastaud...worked perfectly and solved my giant database issue