Stalled custom field development

[Sean McAfee]

Myk Melez <myk at mozilla.org> wrote:
>Sean McAfee wrote:
>>Conceivably, a program
>>might resume after such an operation and find that its notion of the schema
>>is no longer current, probably leading to nasty errors.  Is this acceptable?

>What program?

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

>And how does this differ from FAD custom fields?  FAC 
>doesn't modify the standard schema,

Fields can live in BUGS under your proposal; is this not part of the
standard schema?

>and third-party applications that 
>rely on custom fields will break whether the schema being modified is 
>FAC or FAD.

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.

>>If you agree with me that these are important issues, is the full power of
>>generality in this approach really worthwhile?

>No,

Well, OK then.  Why is it there?  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.  What is
gained by the DB-level field-shuffling your proposal permits?  Performance?
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?  If the advantage is
not in performance, then what is it?

>but neither is the generality available in FAD.  What is worthwhile 
>in FAC is its alignment with the Bugzilla codebase and standard fields; 

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.

>adherence to the ER modeling used in most database applications and for 
>which relational databases are optimized, and better security.

Better security?  Elaborate, please.


--Sean