1. 11 May, 2016 3 commits
    • Rafael Monnerat's avatar
      CloudPerformanceUnitTestDistributor: Hardcode TestSuite Name · a8dc0b12
      Rafael Monnerat authored
        The parameter test_suite_title passed do not correspond exactly to test_suite_title present on ERP5 (as this test is not supposed to share the effort to run tests
      a8dc0b12
    • Georgios Dagkakis's avatar
      Jabber multiline · d161f838
      Georgios Dagkakis authored
      erp5_web_jabber_client: Allow user to send multi-line messages
      
      User can change between single-line and multi-line mode
      using one button.
      
      /reviewed-on nexedi/erp5!114
      d161f838
    • Vincent Pelletier's avatar
      Base_generateTicketUseDomain: Accelerate on large document sets. · a08a3c33
      Vincent Pelletier authored
      The set of resources correponding to a given (non-strict) use is generally
      constant, while the number of documents having relations to these
      resources will increase over a site's life.
      
      The original query used 2 joins:
      - catalog to category for document/resource relation
      - category to category for resource/use relation
      
      Given several tables joined together, MySQL query optimiser will try
      to first execute a query on the table which will yield the fewest rows.
      
      As a result of all the above, query optimiser would end up choosing to
      first find which resources have a use relation to given uid, and only after
      find which documents have a resource relation to these. Which means it
      cannot use any index on the documents themselves, and only an index
      on resource's use... Leading to extremely poor performance on large data
      set when, for example, trying to list the few documents in a given state
      which also have a resource of selected use.
      
      Instead, lookup the list of resources per (non-strict) use when building
      the domain tree, and put that pre-computed uid list as membership
      criterion: catalog query is then only a single-join, whose execution is
      trivial to plan.
      a08a3c33
  2. 10 May, 2016 7 commits
  3. 09 May, 2016 3 commits
  4. 06 May, 2016 2 commits
  5. 05 May, 2016 3 commits
  6. 04 May, 2016 8 commits
  7. 03 May, 2016 8 commits
  8. 02 May, 2016 3 commits
  9. 29 Apr, 2016 3 commits