Stalled custom field development

[Myk Melez]

Sean McAfee wrote:

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

>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?  If not, adding columns to the bugs table will have 
no effect on access by those programs.

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

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

>What is
>gained by the DB-level field-shuffling your proposal permits?  Performance?
>  
>
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.

>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?
>
Database theory dictates that there should be demonstrable differences, 
and if I recall correctly the tests I did earlier showed some in practice.

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

    * 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.
    * 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.
    * 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.
    * 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.
    * One of the options on Gerv's list of options for Bugzilla
      installations looking for custom fields
      <http://www.gerv.net/hacking/custom-fields.html> is to co-opt an
      existing field, and discussion on n.p.m.webtools indicates this
      option has frequently been used successfully.


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

-myk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20050328/972741e3/attachment.html>