1. 17 Oct, 2019 2 commits
  2. 16 Oct, 2019 1 commit
  3. 15 Oct, 2019 2 commits
  4. 14 Oct, 2019 1 commit
  5. 11 Oct, 2019 2 commits
  6. 10 Oct, 2019 7 commits
  7. 09 Oct, 2019 7 commits
  8. 08 Oct, 2019 4 commits
  9. 07 Oct, 2019 7 commits
  10. 05 Oct, 2019 3 commits
  11. 04 Oct, 2019 4 commits
    • Optimize WorkflowHistoryList · 1ca655a3
      This is done by inheriting most of the code of ConflictFreeLog,
      i.e. using a doubly-linked list:
      - for fast iteration of the first elements, and in particular
        immediate access to the first element (used for creation date);
      - that keeps track of the history length;
      - that implement fast reverse iteration (although it could
        have been done without changing the data structure).
      
      The size of buckets is not fixed anymore to 16 items:
      like ConflictFreeLog, WorkflowHistoryList is also a good candidate
      to look at the estimated serialized size of the bucket in order to
      decide if elements should be added to a new one or not.
      Then developers won't have to care about using Pdata or not.
      
      The size is bigger than the ConflictFreeLog default,
      because workflow items look a lot alike and adding
      a few more is cheap when the ZODB compresses.
      
      No more optimized __getstate__ (except for workflow histories that
      have not been migrated) so BT export will be a bit more verbose.
      
      The BBB code is because of
        !934
      
      /reviewed-on !941
      Julien Muchembled committed
    • ZODB Components: Before migrating Interfaces from FS, there must be one Interfac… · 694c9fee
      …e class per source file matching its name.
      
      Same as Document class: this avoids registering Interfaces at startup and just do it
      when using the Interface. In assuming that portal_components/XXX has a class
      name equals to XXX.getRference(), it is easier to:
       * List all existing Interfaces (for example in Portal Type Class view): getReference()
         on all validated 'Interface Component' in portal_components.
       * Lookup for an 'Interface Component': 'from erp5.component.interfaces.XXX import XXX'.
      Arnaud Fontaine committed
    • ZODB Components: Properly handle addition of template_* properties in BusinessTe… · d9627917
      …mplate PropertySheet.
      
      On the plus side, this avoids an ugly 'except AttributeError: pass' which does
      not work anyway with the scenario below.
      
      Assuming the following:
        * template_XXX Property (accessor: getTemplateXXX) recently added to BusinessTemplate PropertySheet.
        * erp5_YYY sets template_A Property (erp5_YYY/bt/template_XXX.xml).
        This commit handles the following:
          1. Stop instance with old ERP5 without template_XXX.
          2. Update erp5.git.
          3. Start instance.
          4. Upgrade erp5_property_sheets and erp5_YYY bt5s in *one* transaction from portal_templates UI.
          => When upgrading erp5_YYY, BusinessTemplate.importFile() imports erp5_YYY/bt/*.xml where the
             list of files is based on BusinessTemplate class propertyMap(), but at this point accessors
             have not been re-generated yet, thus template_XXX is not returned by propertyMap() and
             erp5_YYY/bt/template_XXX.xml is not imported.
             => portal_templates/erp5_YYY new BT does not have template_XXX property set at all.
      Arnaud Fontaine committed
    • Default ERP5 instanciation uses following schema for naming all zope nodes: · 0a66e514
        <family_name>-0..9 when number of nodes <= 10
        <family_name>-01..09 (or n) when number of nodes > 10
      
      In scalability tests instance keeps track of old used nodes and when nodes > 10
      will pick by default sort "activity-0" which is NO longer an existing zope process.
      This is an ugly fix and real woraround is to have something like activities-000x schema by default
      Ivan Tyagov committed