The auto-updating timestamp fields are a pain. They're not cross-db compatable, and we keep forgetting to stop updating them. See bug 153578, among others. Instead of using the mysql timestamp type, we should use the mysql datetime type (which is the same as the ANSI/SQL timestamp type), and assign into it where needed.
Target Milestone: --- → Bugzilla 2.18
Yes. This rules.
Yes we should do this for XDB reasons, but we shouldn't kid ourselves this will solve the forgetfulness. It will simply change forgetting to not change to forgetting to change, which is arguably a worse problem. The only solution to that is a bug change API that forces you to specify whether to update the timestamp (or works it out itself).
There are fewer places we do need to change (ie once in post/process_bug) vs those we don't (everywhere else is post/process_bug, updating lastchanged for email, updating keywords cache, product/component until bug 43600 is fixed, etc) Attachments use this as a creation time only, but get this wrong... Its a mess, and we don't need it.
Priority: -- → P1
Unloved bugs targetted for 2.18 but untouched since 9-15-2003 are being retargeted to 2.20 If you plan to act on one immediately, go ahead and pull it back to 2.18.
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
For databases that support triggers, they provide an easy method to ensure timestamps are updated automatically, as required.
True, but we only sometimes want the field to be updated, and bugzilla sometimes gets it wrong when we forget. Its not really intuitive to have to specify hen a field update doesn't happen.
Can't the logic for when the field should be updated be coded into the trigger?
See, that's exactly the problem though. MySQL *does* have an implicit trigger. And it always fires *any* time the row is touched. Which means you have to specifically override it when you don't want it to fire. For most of the cases where Bugzilla uses it, it would be much more intuitive for the developers if we set the field manually any time it changes. We did end up setting it manually on Sybase. Sybase does have real triggers where you can code whatever you want in them. But it was easier to teach Bugzilla how to set the timestamp than to create the trigger in Sybase. And letting Bugzilla know how means we don't have to do something specific for every database Bugzilla eventually runs on.
You can't really give enough context in a trigger, unless we go to stored procedures. anyway, mysql doesn't do triggers or stored procedures, and we want the same mechanism for both.
It seems that we agreed that this is a good think to do, so I just created a new bug 257303 with patch attached to convert lastused in logincookies table and I will do the same with delta_ts in bugs table as soon as the patch is finished.
Depends on: 257303
Added bug with patch for delta_ts in bugs table.
Depends on: 257315
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
The "delta_ts" attribute in the "bugs" table was the last one to use the timestamp format. This has been fixed! :)
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Priority: P1 → --
Resolution: --- → FIXED
Target Milestone: Bugzilla 2.22 → Bugzilla 2.20
You need to log in before you can comment on or make changes to this bug.