Stalled custom field development

[Sean McAfee]

Myk Melez <myk at mozilla.org> wrote:
>Sean McAfee wrote:
>>Fields can live in BUGS under your proposal; is this not part of the
>>standard schema?

>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?

No, and no.

>If not, adding columns to the bugs table will have 
>no effect on access by those programs.

Adding, no.  Deleting, yes.

>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.

No, it won't.  A schema change under FAC can cause a hapless program to
generate invalid SQL, which little if any existing Bugzilla code I've seen
checks for explicitly.  This can't happen under FAD.

>>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.

>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.

Fine, then.  Pick a starting design and advocate it.  Really, there seems to
be little sense of immediacy in your plans, just a lot of cans and coulds.
Do you have any sense of a development timeline for FAC?  Who's going to be
working on it, and when?  Would custom fields even be under discussion if I
weren't pushing my design?  I get the sense that they wouldn't.  Is however
long you envision FAC will require to design and implement worth the delay
when there's a FAD implementation available right now which is, at the VERY
LEAST, adequate, even if not ideal?

>>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.

>The evidence shows otherwise:
[snip]

Most of the evidence you cite assumes that a "custom field" is defined as a
field which applies universally, to all bugs in an installation.  An
important feature of my own notion of custom fields is that they can be
applied selectively on a per-product basis.  To avoid confusion in the
future, perhaps we need additional terminology that makes this difference
explicit.  If all I needed were the universal kind of fields, I'd have saved
myself a lot of trouble and just thrown everything into BUGS.

>>Better security?  Elaborate, please.

>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.

I can't tell when you mean schema in the database-structure sense, or in the
database-structure-plus-field-metadata sense you mentioned earlier.  If you
mean only the former, FAD certainly doesn't care if the schema is locked.
Otherwise, well, SQL injection vulnerabilities are bad news in any case.
Isn't this why all Bugzilla CGIs have taint mode on, anyway?


--Sean