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