Bug #90841

DataHandler-Bugfix: When "sorting"-field of DB-record will be updated, then the "tstamp"-field of that DB-record should also be updated

Added by Jürgen Kußmann 13 days ago. Updated 9 days ago.

Status:
Under Review
Priority:
Should have
Assignee:
-
Category:
DataHandler aka TCEmain
Target version:
Start date:
2020-03-26
Due date:
% Done:

0%

TYPO3 Version:
8
PHP Version:
Tags:
Complexity:
no-brainer
Is Regression:
Sprint Focus:

Description

When the "sorting"-field of a DB-record (e.g. tt_content-record) will be updated, than also the 'tstamp'-field of that related DB-record should be updated. In our TYPO3-installation, we use the "tstamp"-field of DB-records to check, if the DB-record has changed. So, for us, it's very, very important, that the "tstamp"-field will always be updated, when the DB-record will change. So, this litle bugfix is crucial for us.

The bugfix is a no-brainer and easy to implement/adopt. The bugfix works fine in TYPO3 8. The same bug also exists in TYPO3 v9 and v10, so you have to fix the bug also for that versions.

Best regards,
Jürgen Kußmann
Software Developer
AOE GmbH

Update-tstamp-of-record-when-sorting-will-be-updated.diff View (1.38 KB) Jürgen Kußmann, 2020-03-26 13:27

History

#1 Updated by Benni Mack 13 days ago

Hey Jürgen,

thanks for your report. I guess we would need to check if the history (sys_history) is added there as well (this is usually an info that the record was modified).

#2 Updated by Oliver Hader 12 days ago

Hi Jürgen, nice to read from you here again :)

From an EventSourcing point of view (we don't have EventSourcing in the core) I totally get to point to check what has changed and only process/project those changes - e.g. trigger rendering of pages that were changed or warm-up their caches again.

Usually the meaning of "tstamp" was "modified by editor" which actually would not be the case when the sorting value was updated because some other record was inserted and sorting values had to be reprocessed.

I need to think a little bit about potential implications...

#3 Updated by Jürgen Kußmann 12 days ago

Hi Oli,
there are several code examples inside the DataHandler-class, where the tstamp (of a none editor changed DB-record) is updated. The "position" where i added the logic to update the tstamp was only the last one, which didn't contain such a logic. Man könnte also sagen, dass durch meinen Fix die Logik (zum updaten des tstamps) in der DataHandler-Klasse nun überall vorhanden ist - und nicht nur lückenhaft ;-)

Oliver Hader wrote:

Hi Jürgen, nice to read from you here again :)

From an EventSourcing point of view (we don't have EventSourcing in the core) I totally get to point to check what has changed and only process/project those changes - e.g. trigger rendering of pages that were changed or warm-up their caches again.

Usually the meaning of "tstamp" was "modified by editor" which actually would not be the case when the sorting value was updated because some other record was inserted and sorting values had to be reprocessed.

I need to think a little bit about potential implications...

#4 Updated by Oliver Hader 12 days ago

Alright then... I did not check in detail when tstamp is updated and when not... if it's updated in other places as well, I'm fine with completing the missing spots

#5 Updated by Gerrit Code Review 11 days ago

  • Status changed from New to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/63961

#6 Updated by Gerrit Code Review 11 days ago

Patch set 1 for branch TYPO3_8-7 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/63962

#7 Updated by Oliver Hader 11 days ago

#8 Updated by Jürgen Kußmann 9 days ago

Hi Oli,
i can't login at https://review.typo3.org. But nevertheless, the code looks good for me at https://review.typo3.org.

Best regards,
Jürgen

Oliver Hader wrote:

Also available in: Atom PDF