Closed Bug 156834 Opened 19 years ago Closed 17 years ago

Remove timestamp fields

Categories

(Bugzilla :: Bugzilla-General, defect)

2.17
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Bugzilla 2.20

People

(Reporter: bbaetz, Assigned: bbaetz)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [schema])

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.
Whiteboard: [schema]
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.
Blocks: 176979
Blocks: bz-sybase
Priority: -- → P1
OS: Linux → All
Hardware: PC → All
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
Closed: 17 years ago
Priority: P1 → --
Resolution: --- → FIXED
Target Milestone: Bugzilla 2.22 → Bugzilla 2.20
Blocks: 288083
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.