<!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">
Max Kanat-Alexander wrote:
<blockquote cite="mid1106705126.3713.33.camel@localhost.localdomain"
 type="cite">
  <pre wrap="">On Tue, 2005-01-25 at 14:12 -0800, Myk Melez wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Plugins can be roughly divided into three categories:
[snip]
    </pre>
  </blockquote>
  <pre wrap=""><!---->
        OK. Fair enough.

        My experience is that implementations which try to predict the future,
and limit themselves in design to only what they predict, are doomed to
failure. That's why I'm in favor of FAR, because it's more extensible. I
can't know what types of plugins people will create, so I'd rather give
them as many options as possible.
  </pre>
</blockquote>
In my experience it's just as dangerous to overgenericize because
someone might need some capability you don't know about yet.  But FAC
doesn't limit the use of custom fields by plugins, and it allows
installations and plugins to create just as many and as varied custom
fields as FAD.  How is FAD more extensible?<br>
<br>
<blockquote cite="mid1106705126.3713.33.camel@localhost.localdomain"
 type="cite">
  <pre wrap=""> As a single example, what if I created a single plugin that was
"Project Management for Bugzilla?"
  </pre>
</blockquote>
Ok, let's say you did.  How does that inform this debate?<br>
<br>
<blockquote cite="mid1106705126.3713.33.camel@localhost.localdomain"
 type="cite">
  <pre wrap=""> Fields-As-Data makes it easier to write generic SQL</pre>
</blockquote>
What's generic SQL, why is it important, and how is it easier to write
in FAD?<br>
<br>
<blockquote cite="mid1106705126.3713.33.camel@localhost.localdomain"
 type="cite">
  <pre wrap="">, also, to grab data
out of custom fields, without knowing the type of data in those fields
in advance</pre>
</blockquote>
Not true.  FAD uses field types just as surely as FAC and standard
fields.  Both proposals similarly enable installations to stuff data of
all types into text fields if desired.  But manipulating typeless data
is of limited utility, anyway, and suboptimal (which is why we're
storing data in a database in the first place).<br>
<br>
<blockquote cite="mid1106705126.3713.33.camel@localhost.localdomain"
 type="cite">
  <pre wrap="">, or how we'd have to JOIN in order to get the data,</pre>
</blockquote>
Both proposals store meta-data that tells code how to access custom
fields and when a JOIN will be necessary in a meta-data table (either
by extending fielddefs or creating an equivalent).  With FAC, it may
sometimes be possible to derive this information from a form field
name, which is easier than looking it up in the meta-data table. 
Otherwise, FAC will do the lookup, but FAD will too.  How is it easier
with FAD, and why does that matter?<br>
<br>
<blockquote cite="mid1106705126.3713.33.camel@localhost.localdomain"
 type="cite">
  <pre wrap="">or even
having to modify the SELECT statement in a fashion that can't use
placeholders.
  </pre>
</blockquote>
How does FAC make it harder to use placeholders?<br>
<br>
<blockquote cite="mid1106705126.3713.33.camel@localhost.localdomain"
 type="cite">
  <pre wrap=""> To be honest, I haven't tried to implement it either way, personally. I
know that Sean has. I think he used Fields-As-Data, and I think his
implementation is working nicely at Transmeta.
  </pre>
</blockquote>
It's possible to implement custom fields via either approach, and it's
likely that either approach will work on a given installation, but
we're trying to figure out the best approach for all Bugzilla
installations and developers, and while the success of an approach on
one site can inform the debate, it can't decide it.<br>
<br>
While weighing
Sean's success with FAD at his installation, we should also weigh the
success of FAC on hundreds of Bugzilla installations for a number of
years, both for standard fields and for custom ones, not to mention the
general success of FAC in database design.<br>
<br>
<blockquote cite="mid1106705126.3713.33.camel@localhost.localdomain"
 type="cite">
  <pre wrap=""> Of course, Fields-As-Columns is the way that Bugzilla works now. Except
for things like longdescs, which is a sort of Fields-As-Data thing.
  </pre>
</blockquote>
longdescs isn't FAD at all, it stores comment entities which
have attributes represented by columns and whose rows each represent a
unique instance of a comment.  It's a classic example of an object
modeled by a table, just
like the bugs, attachments, and users tables.<br>
<br>
-myk<br>
<br>
</body>
</html>