Child pages
  • [unit configs] Unit setting colletions
Skip to end of metadata
Go to start of metadata

Imported From:

  1. Right now we collect some unit config settings (e.g. RewriteListenersAggregatedTags) into a collections, that are stored in kApplication class instance.
  2. Also we cache all collections however we must create instances of all objects that store collections on In-Portal start even if they won't be used (e.g. aggregated tag list).

If we'll be implementing tag filter concept (see [template parser] Tag filter concept [5.3.0-B1]), then we'll have one more collection as a result. Currently collection adding and using isn't very straight forward process and we should work to make it easier to use. To solve this we might need to separate cache into one, that is used at every page and other on-demand caches. However that might result in additional sql queries (1 extra sql query per cache restore) if Memcache isn't used.


  1. I have another idea to solve problem described in *2.* item:

    Create 2 classes:

       - kUnitSettingCollection - data collected for a single settings across
       all unit configs
       - kUnitSettingCollections - all created collections

    Class kUnitSettingCollection would have following methods:

       - scan/process(kUnitConfig $unit_config)
       - add($key, $value)
       - getFromCache()
       - setToCache($data)

    Class kUnitSettingCollections would have following methods:

       - getCollectionBySettingName($setting_name)
       - addCollection(kUnitSettingCollection $collection)

    At the end we'll have all collections in an easy manageable form - objects.
    Then we can:

       1. store them (serialize) in cache more easily
       2. use them in corresponding classes only when classes are instantiated
       3. easy way to apply custom processing to collection elements (e.g.
       rewrite listener sorting) by extending kUnitSettingCollection class

  2. Hi Alex,

    My main questions are - does it impact (rank from 1 - 5):

    1. Developer (development process from how it's done now): old / new

    2. Performance: old / new

    3. Flexibility: old / new



  3. They all should stay the same, because unit config format doesn't change.
    What changes is only way how data, collected from unit configs is being

    Since we add new collections very rarely, then this improvement (that
    should easy adding of new collections), won't be much of improvement right
    away. But I see no point in adding new collection old way if we can improve
    the process for further collections.

  4. Thanks for clarification.

    Please create this task for 5.3.0 then