Bug #90841
open
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 over 4 years ago.
Updated over 4 years ago.
Category:
DataHandler aka TCEmain
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
Files
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).
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...
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...
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
- Status changed from New to Under Review
- Status changed from Under Review to New
- Target version deleted (
next-patchlevel)
- Complexity deleted (
no-brainer)
Also available in: Atom
PDF