[MDEV-30553] Trigger Timestamp Created: 2023-02-02 Updated: 2023-11-28 |
|
| Status: | Confirmed |
| Project: | MariaDB Server |
| Component/s: | Data Manipulation - Update, Triggers |
| Affects Version/s: | 10.5.16 |
| Fix Version/s: | 10.4, 10.5, 10.6, 10.11 |
| Type: | Bug | Priority: | Major |
| Reporter: | David Meissner | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Centos 7 VMware |
||
| Description |
|
I am having an issue here. If anyone has any ideas how to resolve it, it would be greatly appreciated. [BACKGROUND] I have two identical tables called test and test_history. There is a timestamp column in each entitled 'modified_at' and in the 'test' table, that column will update to current_timestamp if anything in the row was changed (ON UPDATE CURRENT_TIMESTAMP). If the row was not changed, that value remains the same. This works as designed. On 'test' I have an AFTER UPDATE trigger that should fire ONLY if the row has changed and insert a copy of the OLD record into the 'test_history' table. Here is the AFTER UPDATE trigger. ------------ IF (NEW.modified_at <> OLD.modified_at) THEN END [ISSUE] The code appears to fine, BUT the 'NEW.modified_at' value IS NOT the value of the modified_at column after an update query on a row has run. If the update results in 0 rows changed and the 'modified_at' value remains the same, 'NEW.modified_at' does not equal that value. The 'NEW.modified_at' value actually equals the current timestamp that the trigger fired. I know this to be the case because I inserted both OLD.modified_at and NEW.modified_at into another table and NEW.modified_at is the time that the update was performed (trigger fired), even when nothing changes in the row. Any help on this is greatly appreciated. I am hoping to not cycle through all the columns looking for changes in order to fire the trigger. Thanks in advance. |
| Comments |
| Comment by Sergei Golubchik [ 2023-02-02 ] |
|
NEW.modified_at is set to CURRENT_TIMESTAMP before the BEFORE UPDATE trigger, so that the trigger could see correct values that are going to be written into the table. Technically it's possible to reset NEW.modified_at back to its old value before invoking the AFTER UPDATE trigger. Sounds kind of weird though, the field changes between the BEFORE and AFTER trigger without user doing anything |