<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Sean McAfee wrote:<br>
<blockquote cite="mid20050328210022.AAC92BF33@mail.schwag.org"
type="cite">
<pre wrap="">Well, any program. I have about a half-dozen that are regularly run against
our database to provide specialized reports. (Most are short and sweet,
owing to the abstraction provided by my Bugzilla::Query module.)
</pre>
</blockquote>
...<br>
<blockquote cite="mid20050328210022.AAC92BF33@mail.schwag.org"
type="cite">
<pre wrap="">Fields can live in BUGS under your proposal; is this not part of the
standard schema?
</pre>
</blockquote>
<br>
Do any of these programs rely on the order of columns in Bugzilla
tables? They shouldn't, since that order is never guaranteed by
relational databases. Do the programs query the tables for the list of
available fields and die if they find a field that didn't previously
exist? If so, why? If not, adding columns to the bugs table will have
no effect on access by those programs.<br>
<br>
<blockquote cite="mid20050328210022.AAC92BF33@mail.schwag.org"
type="cite">
<pre wrap="">Are you sure you know what you're arguing against? The schema never changes
under FAD. I regard this as a strength of the design.
</pre>
</blockquote>
The database structure may never change under FAD, but the Bugzilla
schema, i.e. the way Bugzilla data is organized, and what data is being
stored, does change under FAD, even if some of it changes in data, and
if a third-party script or program (or Bugzilla itself for that matter)
expects the schema to look a certain way when querying it, then it'll
die if the schema changes out from under it just as surely whether the
schema is all structure or part data.<br>
<br>
<blockquote cite="mid20050328210022.AAC92BF33@mail.schwag.org"
type="cite">
<pre wrap="">I would find FAC far easier to swallow
from a design standpoint if all fields were treated the same--all in BUGS,
all in a single new table, each in its own table, or whatever.</pre>
</blockquote>
Your installation, and others, are welcome to use it like that. And
this complexity will develop over time and with need, so the initial
implementation will be simpler and could stay that way if we never find
a need for the additional complexity. One of the strengths of FAC is
that such complexity is available if it's necessary, although it
doesn't have to be used if it isn't.<br>
<br>
<blockquote cite="mid20050328210022.AAC92BF33@mail.schwag.org"
type="cite">
<pre wrap="">What is
gained by the DB-level field-shuffling your proposal permits? Performance?
</pre>
</blockquote>
Performance and expandability. Performance, because different fields
work better in different configurations, and the different can become
significant for large-scale databases. As for expandability, although
tables have very high column length limits in modern databases, there
are still limits, so enabling the use of multiple tables means we can
support an unlimited number of custom fields rather than just thousands.<br>
<br>
<blockquote cite="mid20050328210022.AAC92BF33@mail.schwag.org"
type="cite">
<pre wrap="">What kind of differences would one expect between the various storage
mechanisms? Are they demonstrably large enough to be noticeable and/or
significant, or are you just assuming that they are?</pre>
</blockquote>
Database theory dictates that there should be demonstrable differences,
and if I recall correctly the tests I did earlier showed some in
practice.<br>
<br>
<blockquote cite="mid20050328210022.AAC92BF33@mail.schwag.org"
type="cite">
<pre wrap="">As I've said before, custom and standard fields are different beasts, and
there's no a priori reason to assume the same approaches are warranted.
</pre>
</blockquote>
The evidence shows otherwise:<br>
<ul>
<li>Existing custom fields on prominent Bugzilla installations (f.e.
the "fixed in" field on bugzilla.redhat.com) work similarly to standard
fields, where by "work" I mean appear in forms together, are searched
and modified as standard fields are, etc.<br>
</li>
<li>Discussion of new fields frequently includes debate about whether
they would be popular enough to be standard fields or should be left
for installations to implement as custom fields (see f.e. time tracking
bug 24789). Although field interdependence complexities make some
fields impossible to implement as custom fields using a basic custom
fields implementation (as in the case of time tracking), there is no
debate about whether the fields would work differently from standard
fields.<br>
</li>
<li>We have often discussed converting a number of standard fields to
custom fields because they don't make sense for many installations, but
we have never discussed changing the way those fields work so that
would work differently from how they currently work as standard fields
or how standard fields generally work.</li>
<li>The closest equivalent to custom fields in the Bugzilla codebase
today, fields like QA Contact and Target Milestone, which can be
individually disabled by installations that make no use of them, and in
some cases come disabled by default, work the same as standard fields.</li>
<li>One of the options on <a
href="http://www.gerv.net/hacking/custom-fields.html">Gerv's list of
options for Bugzilla installations looking for custom fields</a> is to
co-opt an existing field, and discussion on n.p.m.webtools indicates
this option has frequently been used successfully.<br>
</li>
</ul>
<br>
<blockquote cite="mid20050328210022.AAC92BF33@mail.schwag.org"
type="cite">
<pre wrap="">Better security? Elaborate, please.
</pre>
</blockquote>
With FAC, you can limit schema changes to a separate database user, and
you can limit access to that user to command-line programs so that
there is no web-based way to modify the Bugzilla schema, even through a
SQL injection vulnerability. With FAD, since part of the schema is
data, a SQL injection vulnerability leaves the database vulnerable to
schema changes.<br>
<br>
-myk<br>
<br>
</body>
</html>