Remove timestamp fields

RESOLVED FIXED in Bugzilla 2.20

Status

()

RESOLVED FIXED
17 years ago
5 years ago

People

(Reporter: bbaetz, Assigned: bbaetz)

Tracking

(Blocks: 2 bugs)

2.17
Bugzilla 2.20
Dependency tree / graph

Details

(Whiteboard: [schema])

(Assignee)

Description

17 years ago
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.
(Assignee)

Updated

17 years ago
Whiteboard: [schema]
Target Milestone: --- → Bugzilla 2.18

Comment 1

17 years ago
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).
(Assignee)

Comment 3

17 years ago
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.
(Assignee)

Updated

17 years ago
Blocks: 176979
Blocks: 173130
Priority: -- → P1

Updated

16 years ago
OS: Linux → All
Hardware: PC → All

Comment 4

15 years ago
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

Comment 5

15 years ago
For databases that support triggers, they provide an easy method to ensure
timestamps are updated automatically, as required.
(Assignee)

Comment 6

15 years ago
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.

Comment 7

15 years ago
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.
(Assignee)

Comment 9

15 years ago
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.

Comment 10

15 years ago
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

Comment 11

15 years ago
Added bug with patch for delta_ts in bugs table.
Depends on: 257315
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22

Comment 12

14 years ago
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

Updated

14 years ago
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.