Custom Fields again

[Bradley Baetz]

On Wed, Dec 11, 2002 at 09:55:43AM -0500, Christopher Hicks wrote:
> All of this worry leads me to feel like we need a better way to manage the
> schema.  (Others have touched on this.)  A variety of schemes exist to do
> this.  It /shouldn't/ be a big deal for people to add (or drop) fields and
> for the software to dynamically figure it out.  Beyond primary keys and
> foreign keys there shouldn't be that much that's sacred. Ultimately, I'd
> like to see the 'core' schema split into the sacred and optional bits.  
> Then local additions and choices regarding the optional core pieces can be 
> stored seperately.

Well, we can find out whats in the schema. Its doing something useful
with it which is the problem. If I know that I have a VARCHAR(x) column
called 'myField', how do I know what its meant to contain?

We really don't want to encourage people to make their own updates to
teh schema manually.

> 
> I'd recommend looking at Alzabo for managing the schema.  We have been
> using an internal system to manage regularly changing schemas and the 
> meta-information about each field.  I'm probably going to migrate all of 
> that onto Alzabo during our next major development cycle.

A lot of the stff in checksetup is more than just creating the fields -
we run conversion code to move stuff arround, too. To an extent, teh
code in checksetup is a manual version of that, which tests for
existance of certain fields, and then does 'stuff' to them

> It was mentioned in the URL against custom fields early in this discussion
> that the more fields that were added the less likely bugs were to be
> submitted.

I don't remember seeing that, and I don't know if its true. To some
extent, it may be - if I can limit my search for possible duplicates to
my specific version/os/etc, then I'm more likely to find the correct
one. OTOH, that argument doesn't hold for something like mozilla, which
is almost entirely cross platform code, wherejsut because it was
reported on windows doesn't mean that it won't happen on the mac.

> A number of uses have been mentioned that indicate this isn't
> real since for a variety of reasons the bug submitters may never be
> exposed to any of these fields.  In our installation we almost totally
> ignore the two platform fields even for our software-oriented bugs since
> what we're doing is web-oriented and we rarely have any platform-specific
> issues.  I'd love to get rid of them, but given the choice of making
> changes that will make upgrading harder and ignoring them, it seems easier
> to just ignore them.  So, the lack of clean customization seems to impede
> our bug tracking process more so than customizability causing problems.
> 

Right, and custfields will let you remove that sort of stuff.

Bradley