<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<body bgcolor="#ffffff" text="#000000">
Shane H. W. Travis wrote:
<pre wrap="">On Fri, 24 Dec 2004, Maxwell Kanat-Alexander wrote:
<pre wrap=""> Indeed. I also recall justdave pointing out (somewhere in the
userprefs-table bug, that I don't recall the number of) that for the
"Bugzilla plugins" idea, we should stick to "columns-as-table-rows,"
because that makes a drop-in plugin for Bugzilla much easier to write. </pre>
I was just about to say the exact same thing, Max.
Reference: <a class="moz-txt-link-freetext"
The comment was made in the User Preferences bug, but the implications are
far-reaching. I cannot help but think that if it matters here, then it would
matter even more for something as large and far-reaching as customized
But preferences and custom fields are very different beasts.
Preferences are data, like the other
real-world objects (users, bugs) we model, while custom fields are
structure, like the data structures we use when modeling those objects.<br>
makes sense to model preferences using the most appropriate combination
of table, column, and row structures (f.e. with set theory, or using an
object-oriented model where table = class, column = property, and row =
instance); but doing so for custom fields just adds an unnecessary
layer of abstraction and complexity.<br>
Custom fields are exactly what relational database columns were
designed for; they fit perfectly into the column metaphor, just as the
standard Bugzilla fields do. They're modifiable via SQL statements
just as easily as the data within them is. And while Bugzilla doesn't
modify its schema very much today, there's nothing inherently more
dangerous about it doing so. You can wipe out your data just as easily
with "DELETE FROM <columnname>" as you can with "DROP COLUMN