Custom fields schema

[Myk Melez]

Max Kanat-Alexander wrote:

>On Tue, 2005-01-25 at 14:12 -0800, Myk Melez wrote:
>  
>
>>Plugins can be roughly divided into three categories:
>>[snip]
>>    
>>
>
>	OK. Fair enough.
>
>	My experience is that implementations which try to predict the future,
>and limit themselves in design to only what they predict, are doomed to
>failure. That's why I'm in favor of FAR, because it's more extensible. I
>can't know what types of plugins people will create, so I'd rather give
>them as many options as possible.
>  
>
In my experience it's just as dangerous to overgenericize because 
someone might need some capability you don't know about yet.  But FAC 
doesn't limit the use of custom fields by plugins, and it allows 
installations and plugins to create just as many and as varied custom 
fields as FAD.  How is FAD more extensible?

>	As a single example, what if I created a single plugin that was
>"Project Management for Bugzilla?"
>  
>
Ok, let's say you did.  How does that inform this debate?

>	Fields-As-Data makes it easier to write generic SQL
>
What's generic SQL, why is it important, and how is it easier to write 
in FAD?

>, also, to grab data
>out of custom fields, without knowing the type of data in those fields
>in advance
>
Not true.  FAD uses field types just as surely as FAC and standard 
fields.  Both proposals similarly enable installations to stuff data of 
all types into text fields if desired.  But manipulating typeless data 
is of limited utility, anyway, and suboptimal (which is why we're 
storing data in a database in the first place).

>, or how we'd have to JOIN in order to get the data,
>
Both proposals store meta-data that tells code how to access custom 
fields and when a JOIN will be necessary in a meta-data table (either by 
extending fielddefs or creating an equivalent).  With FAC, it may 
sometimes be possible to derive this information from a form field name, 
which is easier than looking it up in the meta-data table.  Otherwise, 
FAC will do the lookup, but FAD will too.  How is it easier with FAD, 
and why does that matter?

>or even
>having to modify the SELECT statement in a fashion that can't use
>placeholders.
>  
>
How does FAC make it harder to use placeholders?

>	To be honest, I haven't tried to implement it either way, personally. I
>know that Sean has. I think he used Fields-As-Data, and I think his
>implementation is working nicely at Transmeta.
>  
>
It's possible to implement custom fields via either approach, and it's 
likely that either approach will work on a given installation, but we're 
trying to figure out the best approach for all Bugzilla installations 
and developers, and while the success of an approach on one site can 
inform the debate, it can't decide it.

While weighing Sean's success with FAD at his installation, we should 
also weigh the success of FAC on hundreds of Bugzilla installations for 
a number of years, both for standard fields and for custom ones, not to 
mention the general success of FAC in database design.

>	Of course, Fields-As-Columns is the way that Bugzilla works now. Except
>for things like longdescs, which is a sort of Fields-As-Data thing.
>  
>
longdescs isn't FAD at all, it stores comment entities which have 
attributes represented by columns and whose rows each represent a unique 
instance of a comment.  It's a classic example of an object modeled by a 
table, just like the bugs, attachments, and users tables.

-myk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20050127/247a9710/attachment.html>