1. 02 Aug, 2018 1 commit
  2. 01 Aug, 2018 9 commits
  3. 31 Jul, 2018 6 commits
  4. 30 Jul, 2018 12 commits
  5. 29 Jul, 2018 6 commits
  6. 28 Jul, 2018 5 commits
    • totten's avatar
      Overview · 70423e0d
      totten authored
      ```-------------------------------------
      `CRM_Utils_System::flushCache()` calls `CRM_Utils_Cache::singleton()->flush()`.
      In `5.3`, this triggered a cascading effect; in development of `5.4.alpha`,
      some of the cascades were overzealous and we revised to get tighter control
      over cascading.
      
      With an aim to being conservative and reproducing old behavior, I previously
      patched `5.4.alpha` to add several extra flushes and simulate the old cascades.
      However, it wasn't really as conservative as hoped -- because the "old
      behavior" depended on the environment.  This patch brings us closer the "old
      behavior".
      
      See also: #284
      
      Before (Behavior in version <=`5.3`)
      ```
      
      -------------------------------------
      
      On systems with memory-backed caches, `flushCache()` had an aggressive
      cascading side-effect where several named caches (`settings`, etc) were also
      flushed.
      
      On systems with a default configuration (SQL+ArrayCache), `flushCache()` had a
      very limited cascading effect -- it *only cleared the in-process ArrayCache*.
      The bulk of the cache content was preserved in SQL.
      
      Before (Behavior in version ~= `5.4.alpha`)
      ----------------------------------------
      
      To simulate the cascading effect, `flushCache()` explicitly flushes a
      half-dozen individual caches.  (These half-dozen are chosen to match the old
      cascade list and exclude some new things which would problematic.)
      
      On systems with memory-backed caches, this reproduces the aggressive cascading
      effect.
      
      On systems with a default configuration (SQL+ArrayCache), this amplifies the
      flushing -- because it also destroys the underlying SQL caches.
      
      This has the side-effect of significantly degrading performance of the test
      suite.
      
      After (Behavior with patch)
      ----------------------------------------
      
      `CRM_Utils_System::flushCache` calls `CRM_Utils_Cache::singleton()->flush()`.
      
      To simulate the cascading effect, `flushCache()` explicitly flushes a
      half-dozen individual caches...  *but only on memory-backed* systems.
      
      On systems with memory-backed caches, this reproduces the aggressive cascading
      effect.
      
      On systems with a default configuration (SQL+ArrayCache), this is closer to the
      old behavior.  The bulk of the cache remains available in SQL.
      
      Based on local spot-checking, this restores performance of the test suite.
      
      Comments
      ----------------------------------------
      
      Deep down, I don't really believe the cascading effect is a good thing.  At
      some point, I'd rather just remove these bits.  But in absence of a crystal
      ball to predict the side-effects of that, I think it's good to find a better
      approximation of the old behavior.
      70423e0d
    • eileen's avatar
      Merge pull request #12588 from mattwire/5.4_backportcasefixes · 964025e5
      eileen authored
      Backport "Fix regression on case export" to 5.4
      964025e5
    • Seamus Lee's avatar
      a7e59a48
    • eileen's avatar
      Fix regression on case export from recent export fix · f79d8a1e
      eileen authored
      https://github.com/civicrm/civicrm-core/commit/3b4adc92793dccfa446cf66f0740edb543f110d7 changed the way componentmode is defined
      
      It now seems inconsistent
      f79d8a1e
    • Matthew Wire's avatar
  7. 27 Jul, 2018 1 commit