Closed (fixed)
Project:
Entity Construction Kit (ECK)
Version:
7.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
12 Apr 2013 at 13:52 UTC
Updated:
1 May 2014 at 06:47 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
regilero commentedSo here is a very simple patch to replace drupal_cron_run() by a drupal_flush_all_caches();
But do we need this cache flush? do we need some special cron to run? It this related to #1513952?
Comment #2
fmizzell commentedI can not think of any good reason of why that cron run should be there. I can imagine ECK calling cron when a bundle or entity type is deleted, since fields are softly deleted, and this can cause weirdness, but I can not think of any reason why cron should be run after deleting an entity. Let's get some reviews, but this should be an easy commit.
Comment #3
hughworm commenteddrupal_flush_all_caches() is still very heavy handed.
cache_clear_all() seems better.
Comment #4
tahiticlic commentedCan someone explain why it is here ?
It's indeed a huge performance hole...
Comment #5
pounardNo cache should be dropped on a single entity delete, except entitycache module cache if enabled and supported, and potentially field cache for the given entity, but that should be done implicitely if fields are handled well.Sorry I was wrong. No cache delete at all is needed there, ECK module relies on Entity API module which will already do whatever cache needs to be dropped by itself. This line must just be removed.
Comment #6
fmizzell commentedWhen I first started working with ECK, I found some weird behavior coming from Field API, due to lingering data. If I remember correctly a cron run solved the problem, but that is an awful hack. It's been a couple of year since the initial ECK code was written, so I would say, let's just clean up stuff that doesn't seem to make sense and we will see is we get bug reports later.
Comment #7
pounardAgreed, this will resolve an unstainable performance problem. Entity API evolved a lot since and I trust it to be more stable now.
Comment #8
pounardComment #9
pounardDid the patch using the 'diff' command, somehow I fear that the git branch may have diverged a lot from current stable release and needed to be able to patch our current running site.
Use
patch -p0 < FILEto apply.Comment #10
heddnMarking as RTBC. The re-roll is only trivial to apply cleanly against HEAD.
Comment #11
fmizzell commented