Stalled custom field development

Max Kanat-Alexander mkanat at kerio.com
Wed Mar 23 08:12:53 UTC 2005


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.

	Of course, we'll have to deal with that situation anyhow, when we move
all field values into the same table. So I suppose that's not even
really an avoidable problem.

	I just figured that FAC was generally the Path of Least Code Change,
when I started to think about how to make status_whiteboard into a
custom field, or how to make any of our current <select> fields into a
custom field.

	The nice thing about FAD, though, is that we get to create our indexes
once, and always know that they are correct.

	And I think your pseudocode looks basically correct, and makes my FAD
concerns seem much less terrible to me.

	-Max





More information about the developers mailing list