1. 25 Nov, 2021 1 commit
  2. 24 Sep, 2021 1 commit
  3. 02 Oct, 2020 1 commit
  4. 15 Apr, 2020 1 commit
  5. 14 Apr, 2020 1 commit
  6. 13 Apr, 2020 1 commit
  7. 02 Dec, 2019 1 commit
  8. 25 Oct, 2019 1 commit
  9. 24 Oct, 2019 1 commit
  10. 15 May, 2019 1 commit
  11. 09 Aug, 2018 1 commit
    • Markus Klein's avatar
      [TASK] Reduce number of needed SQL queries for resorting of records · 9d2f51fa
      Markus Klein authored and Christian Kuhn's avatar Christian Kuhn committed
      This reduces the resorting to require only a single update statement
      in contrast to "number of records" statements.
      It also only updates the records after the current one, so less records
      are touched when resorting.
      Now handling of the sorting value is following:
      - if no record exists: set interval as sorting number
      - if inserted before an element: put in the middle of the existing elements
      - if inserted behind the last element: add interval to last sorting number
      - if collision: move all subsequent records by 2 * interval, insert
        new record with sorting = collision + interval
      Before, in case of the collision all the records from given pid were
      resorted. The first item was getting 512 (2*sortIntervals) as sorting,
      following records were getting value of
      previous record + sortIntervals (768,1024,...).
      I case we have multiple records with the same sorting value,
      resorting will not fix that, but just move them up.
      New algorithm drawback:
      Sorting column values will grow quicker in time as we're always
      increasing the sorting value and never tidying the whole table
      (thus possibly lowering the max used value).
      The current implementation still allows to insert some 80 million
      records per colpos if sizeof(int) is only 32bit.
      A lot more if we have 64bit.
      Changes to the DataHandler->getSortNumber method are mostly comments and
      formatting (added guard clause), no change in behavior except for
      additional sorting by uid. The additional sorting was required to have
      the same test results across database servers.
      Description of updated tests:
      - workspaces/.../IRRE/ForeignField/Publish/DataSet/copyPage.csv
        Now copied tx_irretutorial_1nff_price records have the same
        sorting values/order as original records (1,2,3 instead of 1,3,2).
        So workspace actions result in the same values as live operations.
      - backend/.../Controller/Page/Localization/CSV/DataSet/CreatedElementOrdering.csv
        Order of the records in both languages is kept (before and after the patch),
        It might look wrong that a record 2.5 in translation is between 1 and 2
        and not between 2 and 3, but keep in mind that colpos is taken into account.
        So record 2.5 has just to be after record 1 (only the two are in colpos 0).
      - install/.../Updates/RowUpdater/DataSet/recordsCanBeUpdated.csv
        Order of the records is kept, less records have changed sorting values,
        as now we're just resorting records after the current one.
      - impexp/.../DatabaseAssertions/importPagesAndRelatedTtContentWithDifferentImageToExistingData.csv
        now existing page sorting is not changed when importing data.
      - workspaces/.../IRRE/CSV/Publish/DataSet/moveParentContentToDifferentPageNChangeSorting.csv
        in CSV relation we don't care about the child sorting field as
        the order is determined by the value of the CSV field.
      Resolves: #85300
      Releases: master
      Change-Id: I033acae475be8778d10dfb5d506d63804aa941e0
      Reviewed-on: https://review.typo3.org/57218
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Markus Klein's avatarMarkus Klein <markus.klein@typo3.org>
      Tested-by: Markus Klein's avatarMarkus Klein <markus.klein@typo3.org>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  12. 27 Jul, 2018 1 commit
  13. 17 May, 2018 1 commit
  14. 10 May, 2018 1 commit
  15. 16 Apr, 2018 1 commit
  16. 01 Mar, 2018 1 commit
  17. 30 Nov, 2017 1 commit
  18. 31 Mar, 2017 1 commit
  19. 28 Mar, 2017 1 commit
    • Wouter Wolters's avatar
      [TASK] Streamline return tags in phpdocs · eb049dba
      Wouter Wolters authored and Benni Mack's avatar Benni Mack committed
      The TYPO3 Core currently has no guidline how to handle phpdoc
      comments regarding @return annoations related to "void" and "null".
      In practice, these annotations have no additional value if no additional
      documentation is given.
      With this change, the php-cs-fixer will remove any unnecessary linebreaks
      within the comments above the @return annotation, as well as remove completely
      empty phpdoc comments because the @return annotation is removed.
      Please be aware, that once PSR-5 is accepted, this coding standard
      within the TYPO3 Core will change again, where there are currently
      some further proposal details like inheritance information.
      Resolves: #80454
      Releases: master
      Change-Id: Ie969d720684c0a75919fe5addd1c36ef5b12eb04
      Reviewed-on: https://review.typo3.org/51686
      Reviewed-by: Nicole Cordes's avatarNicole Cordes <typo3@cordes.co>
      Tested-by: Nicole Cordes's avatarNicole Cordes <typo3@cordes.co>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
  20. 16 Feb, 2017 2 commits
  21. 04 Feb, 2017 1 commit
  22. 03 Feb, 2017 1 commit
  23. 03 Jan, 2017 1 commit
  24. 22 Dec, 2016 1 commit
  25. 31 Oct, 2016 1 commit
  26. 26 Oct, 2016 1 commit
  27. 03 Aug, 2016 1 commit
  28. 14 Apr, 2016 1 commit
  29. 18 Mar, 2016 1 commit