Custom fields schema

Nick Barnes Nick.Barnes at pobox.com
Sat Jan 22 22:14:22 UTC 2005


At 2005-01-21 19:09:05+0000, Myk Melez writes:
>     Sean McAfee wrote:
> 
> >Do you have a specific proposal that can be tested?  And, er, I don't want
> >to sound rude, but would you mind testing it yourself?  I've already done
> >quite a lot in that area.
> 
> Ok, I modified construct-tables.pl to add fulltext indexes to the text 
> columns in the tests, create "real-distributed" columns (real columns, 
> but in a separate table rather than the bugs table, which is how a "real 
> columns" custom fields implementation would handle sparse columns), and 
> make distributed and real-distributed versions of the status whiteboard 
> field.

And I think you are both wrong!  As I said before, now is surely not
the time to be making performance measurements of prototype solutions
of the custom fields defect, given that any of the proposed solutions
are plausibly capable of acceptable performance.

First implement a solution.

Then fix the glaring bugs in it.

Then get it into the trunk.

Then deploy it on test sites such as b.m.o. and let people bang on it
with real data.

Then fix the other bugs in it.

*Then* fix any performance problems with it, if necessary by replacing
the database schema part of the overall custom fields solution.

Please.

"Premature optimization is the root of all evil in programming." -
C.A.R. Hoare.

Nick B



More information about the developers mailing list