Custom fields schema

[Max Kanat-Alexander]

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.

	As a single example, what if I created a single plugin that was
"Project Management for Bugzilla?"

	Fields-As-Data makes it easier to write generic SQL, also, to grab data
out of custom fields, without knowing the type of data in those fields
in advance, or how we'd have to JOIN in order to get the data, or even
having to modify the SELECT statement in a fashion that can't 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.

	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.

	-Max
-- 
Max Kanat-Alexander
Technical Support Manager, USA
2350 Mission College Blvd., Suite 400
Santa Clara, CA 95054
Phone: (408) 496-4500
Fax: (408) 496-6902
http://www.kerio.com/support.html