Stalled custom field development

Joel Peshkin bugreport at peshkin.net
Wed Mar 23 17:43:59 UTC 2005


Max Kanat-Alexander wrote:

>On Tue, 2005-03-22 at 22:07, David Miller wrote:
>  
>
>>Max: can you explain to me why FAD requires reworking boolean charts? 
>>We already have fields that require table joins in order to check things 
>>from boolean charts, and if we know the field is in one of these custom 
>>field tables, then that join can be manufactured pretty easily, just 
>>like any of the others.
>>    
>>
>
>	Yes, but imagine that *all* of the fields are in the *same* table. :-)
>So that's only a minor re-working in that case, now that you've pointed
>that out. Joel would know more about this in general than I would,
>though.
>  
>
The problem with the previous patch and the search capabilities was more 
of an implementation issue, as I have previously pointed out.  DO NOT 
create a new table for defining custom fields.  Rather, extend (or 
replace) fielddefs so that it provides information about BOTH standard 
fields and custom fields (regardless of FAC or FAD).  Then,  Search.pm 
can find out what fields exist with a single query and can find out if a 
field is in a column or another table by consulting fielddefs.




More information about the developers mailing list