1. 12 Jul, 2019 1 commit
  2. 10 Jul, 2019 1 commit
    • totten's avatar
      GenCode, Cache::cleanKey() - Fix deploop during clean initialization · 77f080cb
      totten authored
      Suppose you have a clean codebase with no DAO files, and you try to run `xml/GenCode.php`.
      This currently crashes.
      The problem is not symptomatic day-to-day because we commit DAOs, so it's
      very rare to run a full/clean initialization.  However, it does get in the
      way of stress-testing the correctness of GenCode.
      Since 76e697a9, I believe we've had a dependency-loop
      in the clean-gencode scenario, which works as follows:
      * We don't have any DAOs, so we run `GenCode`.
      * Running `GenCode` does a partial bootstrap (i.e. `CRM_Core_Config::singleton($loadFromDB===FALSE)`)
      * The partial bootstrap creates some thread-local caches (`Arraycache`)
      * Before creating the cache, it normalizes the name by calling `CRM_Core_BAO_Cache::cleanKey()`
      * `CRM_Core_BAO_Cache` extends `CRM_Core_DAO_Cache`
      * `CRM_Core_BAO_Cache` doesn't exist - that's why we called `GenCode` at the beginning.
      This migrates the utility function `cleanKey()` to another class which is always available and
      does not rely on DAOs.
  3. 24 Jun, 2019 1 commit
  4. 18 Jun, 2019 1 commit
  5. 16 Jun, 2019 1 commit
  6. 14 Jun, 2019 1 commit
  7. 13 Jun, 2019 1 commit
  8. 05 Apr, 2019 2 commits
  9. 04 Feb, 2019 1 commit
  10. 30 Jan, 2019 1 commit
    • totten's avatar
      Allow rerouting CRM_Core_BAO_Cache::{set,get}Item(s) to PSR-16 drivers · 5a302bbc
      totten authored
      * Requests for `CRM_Core_BAO_Cache` (`setItem($data,$group,$path)`,
        `getItem($group,$path)`, `getItems($group)`, `deleteGroup($group,$path)`)
        are *always* served by two tiers: (1) an in-memory array (`static::$cache`) and (2)
        an SQL table.
      * There is a config option `define('CIVICRM_BAO_CACHE_ADAPTER',
          * When disabled (default), `CRM_Core_BAO_Cache` continues using the old code.
          * When enabled, `CRM_Core_BAO_Cache` changes behavior. Each `$group` is mapped to
            a PSR-16 object.
      * The class/implementation for each `$group` depends on the configuration:
          * In a typical (non-Redis/non-Memcache) deployment, the implementation
            is `CRM_Utils_Cache_SqlGroup`, which has the same 2-tier structure
          * In Redis/Memcache deployment, the implementation combines
            `FastArrayDecorator` with `CRM_Utils_Cache_Redis` or
            `CRM_Utils_Cache_Memcache`.  This gives a similar 2-tier structure
            (e.g. in-memory+Redis).