Stalled custom field development

[Sean McAfee]

Myk Melez <myk at mozilla.org> wrote:
>Sean McAfee wrote:
>>One difficulty for me has been that Myk has yet to fully define his
>>proposal.  Whether fields live in columns all in the same table, all in
>>different tables, or divided between various tables in some fashion, and how
>>the administrator would manage things in the last case, he has never stated,
>>unless I've missed something.

>It's not ambiguity.  In my proposal all three field locations are 
>available, and each can be selected on a per-field basis depending on 
>which location is optimal for a given field.

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.

>But we would choose a good 
>default, automate the selection and updating of a location via 
>administrative UI, and implement support for the locations iteratively, 
>starting with the good default that most fields will use.

This scheme is still practically bereft of details.  Here are just the first
few questions that come to mind:

What is this good default?  Why is it good?

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?

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

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?

How exactly *does* one decide how to store fields?  If there's a
straightforward algorithm for it, it's not obvious to me.

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


--Sean