Custom fields schema

[Christopher Hicks]

On Fri, 21 Jan 2005, Myk Melez wrote:
> It makes sense to model preferences using the most appropriate combination of 
> table, column, and row structures (f.e. with set theory, or using an 
> object-oriented model where table = class, column = property, and row = 
> instance); but doing so for custom fields just adds an unnecessary layer of 
> abstraction and complexity.

Bah.  Your conclusion of what's necessary here seems to be based on a very 
selective view of the universe.  Several "necessities" stick out when 
considering a custom fields implemention based on abstraction at the 
database level:

(1) People can add as many custom fields as they want without worrying 
about reaching the maximum record size of their database

(2) Code for dealing with custom fields is going to need to have a goodly 
portion of the abstraction tables for keeping track of stuff anyways.

(3) Since queries that involve custom fields will now have to be written 
on the fly they are less able to be optimized by using a database that can 
deal with prepare() usefully.

(4) Since queries involving custom fields are going to take a few database 
hits to figure out what the field names so the query could be written you 
end up with cases where 1 query turns into 4 queries.  If the database is 
across a WAN from the bugzilla instance the effect of multiple queries 
where there were one will be more noticable.

(5) Custom fields should be able to be implemented without the bugzilla 
user having database privs to alter tables.

Myk - it sounds like you're basing the decision on what way to go here 
totally based on performance and I think there's a lot more that should go 
into this decision.

-- 
</chris>

"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)