Stalled custom field development

[Myk Melez]

Sean McAfee wrote:

>What three locations are these?  I see only two: the BUGS table and new
>tables for storing one or more fields.  If you're referring to the three
>schemes I outlined, the first two are mutually exclusive.
>  
>
The three locations are:

   1. the bugs table;
   2. a single separate table;
   3. field-specific tables.

All three can be used in a single Bugzilla installation simultaneously.

>What is this good default?  Why is it good?
>  
>
The good default is probably to store custom fields in a single separate 
table because most custom fields are short and sparse.

>How general is this administrative UI going to be?  I can think of plenty of
>possible field-shuffling actions one might want to perform, such as:
>
>*  Move a field from BUGS to another pre-existing field table
>*  Move a field from BUGS to its own new table
>*  Move a field from a field table to BUGS
>*  Move a field from a field table to another field table
>*  Merge a field table into another, or into BUGS
>
>Will the UI support all of these?
>  
>
Maybe, if users demand them, but it will likely support (in order of 
implementation):

   1. moving a field from the single separate table to a field-specific
      table;
   2. moving a field from a field-specific table to the single separate
      table;
   3. moving a field from the single separate table or a field-specific
      table to the bugs table;
   4. moving a field from the bugs table to the single separate table or
      a field-specific table.


>In a large installation, any of these actions might require important tables
>to be locked for the duration of the operation, locking users out for
>possibly a lengthy period as the schema changes.
>
Yes, but schema changes are rare.

>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?  And how does this differ from FAD custom fields?  FAC 
doesn't modify the standard schema, and third-party applications that 
rely on custom fields will break whether the schema being modified is 
FAC or FAD.

>Will the administrator have to be intimately familiar with the Bugzilla
>database schema to be able to make field-storage decisions, or will the
>interface help him to do so in language that's relatively easy to
>understand?
>  
>
The latter.

>How exactly *does* one decide how to store fields?  If there's a
>straightforward algorithm for it, it's not obvious to me.
>  
>
If it's short (in column width, not value length) and dense, put it into 
the bugs table.  If it's short and sparse, put it into the single 
separate table.  If it's long and dense, put it into a field-specific 
table.  If it's long and sparse, put it into a field-specific table.

>If you agree with me that these are important issues, is the full power of
>generality in this approach really worthwhile?
>  
>
No, but neither is the generality available in FAD.  What is worthwhile 
in FAC is its alignment with the Bugzilla codebase and standard fields; 
adherence to the ER modeling used in most database applications and for 
which relational databases are optimized, and better security.

-myk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20050325/80fe1cc8/attachment.html>