1. 18 Sep, 2018 8 commits
  2. 17 Sep, 2018 18 commits
  3. 15 Sep, 2018 1 commit
    • Revert "Folder: call activate on the object instead of portal_activities.activat… · 1cd37609
      …eObject in _recurseCallMethod()."
      
      This reverts commits 3d3ec3cb ((+ fixup), which
      broke recursion to objects that don't inherit ActiveObject, as explained in the
      docstring.
      
      I also think it was wrong in that default activate parameters disappear at the
      end of the transaction whereas _recurseCallMethod may activate itself to avoid
      creating to many activities at once. IOW, it's important that created
      activities are the same no matter where _recurseCallMethod splits the browsing.
      
      This change needed more review, as well as a unit test.
      Julien Muchembled committed
  4. 14 Sep, 2018 6 commits
  5. 13 Sep, 2018 3 commits
  6. 12 Sep, 2018 4 commits
    • erp5_administration: Stop using getObject. · 920655a2
      Also, why make only 2 queries when I can make 2n+1 queries for the same
      result ?
      Vincent Pelletier committed
    • SQLCatalog_deferFullTextIndex{,Activity}: Do not use getObject . · da7e0f0b
      getObject is generally a shortcut for "return self", and on brains for
      traversing to corresponding document.
      Except... Not everywhere. portal_catalog for example defines a completely
      unrelated method which takes a UID as argument and does a query retrieving
      one document. Which is basically totally redundant with its __call__
      method. Still, of course, it is used in several places.
      Also, ERP5Form.Report defines yet another getObject method, taking an
      acquisition context as argument and traversing to some other path.
      
      So do not use getObject (at least until the code recovers some sanity and
      consistency), but getPath + custom activity API. Oh well.
      Vincent Pelletier committed
    • SQLCatalog_deferFullTextIndex{,Activity}: Use serialization_tag . · b41dc8e0
      Just like regular indexations, fulltext indexations are subject to last-commit-wins.
      Which means that it is possible to reach a state where the fulltext table is
      persistently desynchronised from ZODB:
      - start fulltext indexation activity on many documents (typically: 100)
      - modify one of the documents being indexed
      - start fulltext indexation activity caused by this edit, and assume indexation only
      happens for this object
      - commit the single-object indexation (because it is very fast to retrieve fulltext
      data from just one document)
      - commit the many-objects indexation later (because it is much slower to
      retrieve 100 fulltext representations)
      
      As a consequence, cod emust spawn one fulltext indexation activity per
      document, each with the appropriate serialisation tag. Serialisation tag which
      must not conflict with regular indexation, so use a fixed prefix.
      As a consequence of having to spawn one activity per document, use a
      grouping method to still index by batches to amortise transaction overhead.
      Keep the same method_id as before for backward-compatibility (maybe
      dependencies on this value exist, even though it is bad practice).
      Rewrite SQLCatalog_deferFullTextIndexActivity so ot works as a grouping
      method, simplifying it in the process:
      - build parameter_dict with all entries, as we already know all needed keys
      - None is not callable, so test "not None" in just one expression
      - remove whitespace at end of line
      - use GroupedMessage API
      Vincent Pelletier committed
    • fixup! fixup! runTestSuite: support multiple zserver addresses and frontends URLs · 43d16f61
      ''.split(',') is [''] which evaluates to false ...
      e80b37ff was still incorrect
      Jérome Perrin committed