Custom Fields again

[Bradley Baetz]

replying to both posts here...

On Tue, Dec 10, 2002 at 06:07:25PM -0500, David Miller wrote:
> On 12/10/02 2:59 PM -0800, Jonathan Schatz wrote:
> 
> > right now, the current implementation(s) of custom fields in 91037
> > involves a seperate table that contains custom field information. why
> > not directly update the schema in bugs.bugs instead? adding a new custom
> > field wouldn't require any more info than a normal field ( field, type,
> > default).other than rebuilding / recompiling templates (which isn't an
> > impossible problem), the biggest issue i see is searching. perhaps we
> > could break out all of the sql query generation into a seperate module,
> > which would be responsible for knowing which fields do and don't exist.

Well, yes, in theory. But how do you know what 'type' a field is?
numeric, date, or what?

Besides, what does this honestly give you that a 'real' implementation
using a separate table doesn't? The only thing I could see someone
arguing is search performance, and I think designing what would be a
_massive_ hack arround mysql's join behaviour is a really large mistake.
Not to mention that I'm not conviced that we couldn't do it with only a
minor slowdown.

> >
> > i don't know, it's early (for me) and i haven't had a cup of coffee yet,
> > but this is the idea i've been toying with in my head. i'll most likely
> > move ahead with a prototype of this internally against 2.17.1 once i've
> > ported my 2.16.1 changes there, so comments / flames are welcome. i just
> > don't see the need to treat custom fields any differently than "normal"
> > ones...
> 
> This is actually a fair point.

Correct, its a very good point, which I agree with. But see below..

> 
> We already use LearnAboutColumns() to find out what the names of the
> columns are in the bugs table and just look for any field in the bug form
> with the same name to insert into a bug when creating it.  A custom field
> (at least for creating the bug - querying is a separate issue) would simply
> be a matter of editing the enter_bug template to display it, and adding the
> column to the database.  No code changes would even be required.

LearnAboutColumns is a hack, which I want to disappear. Precisly because
it is a hack (and a bit tricky to do cross-db, although it can be done)
But thats not the only issue. You need to deal with:

- fielddefs (which are also a hack, mind you)
- bug_activity
- querying
- reporting/charting
- other stuff I can't think of at the moment

Now, Bug.pm has a list of 'available fields' as the patch of mine which
is still waiting for review, so if everything used bug.pm things would
be great (except for querying, which has special needs)

> 
> I think the main reason nobody's really thought of that is because of the
> limit of 16 indexes on a table, and the bugs table already had that many.
> 

Yeah, and we require myiasm tables now because of that. The real reason
people haven't been anxious to do it is that its ugly.

> Well, we require MySQL 3.22.6 right now, for precisely that reason, because
> 3.22.6 and up allow more than 16 indexes on a table, so that's no longer an
> issue.
> 

3.23.6, you mean :)

> Process_bug.cgi may do things a little more specifically as far as what
> fields are what, so that may take a little more work to be able to change a
> custom field on an existing bug, but creating a bug with custom fields in
> it is trivial.

Well, yes, but again, if we're going to all this trouble, why not
formally define it? I mean, what do people have against a new table? We
can then do stuff like multi-select values, and so on.

The other advantage is that a lot of our current fields can then become
user defined ones, simplifying the logic - we don't have to deal with
status whiteboard and the url differently, since the update and search
logic would be the same. Thered be a 5 line difference in teh templates
to do teh linkification, and tahts done. Similarly for target_milestone
vs os vs platform vs...

Thats what I meant when I said that I agree that we should handle
'custom' fields the same as normal fields - see
http://bugzilla.mozilla.org/show_bug.cgi?id=173127#c1

If we're going to do this (and I don't see why we shouldn't) why not do
it properly?

Bradley