200837 - (sanefields) make [externally visible] field names make sense

Status: NEW

(Bugzilla :: Bugzilla-General, enhancement)

Description

[Myk Melez [:myk] [@mykmelez]]

A number of fields in our database have bad, redundant, clumsy names that repeat
the name of their table or just don't describe the field anymore (if ever). 
That's annoying for developers.  It didn't matter enough to change the situation
when we only hurt ourselves, but the pain is increasing now that we're pushing
out our data via CSS, RDF, and XML for consumption by external developers.

I fixed this with a translation table in buglist.cgi, but then it got broken
again by the check-in for bug 176461.  We still have only a handful of
third-party apps; let's fix this while we still can, either with a translation
table or in the database.  Among others, the following need fixing:

bugs.bug_id -> bugs.id
bugs.bug_severity -> bugs.severity
bugs.rep_platform -> bugs.platform
bugs.assigned_to -> bugs.assignee or bugs.owner
bugs.bug_status -> bugs.status
bugs.short_desc -> bugs.summary

Comment 1

[Myk Melez [:myk] [@mykmelez]]

And: bugs.target_milestone -> bugs.milestone

Milestones have been around for years, and no other kind has yet been invented.

Comment 2

[Gervase Markham [:gerv]]

I agree that if we are going to do this, we should do it all in one go, and
before the next major release.

What's the best implementation strategy? One uber-patch? One field at a time? We
can't really do one file at a time for this, because you can't easily retain
backwards-compatibility.

Speaking of which, what's the migration strategy? And what things are affected?
I can think of:

- Stored queries
- Bookmarks to queries
- XML

Gerv

Comment 3

[Myk Melez [:myk] [@mykmelez]]

User stylesheets for HTML bug lists may also be affected, since their columns
have id attributes to enable users to style them.

RDF output of bug lists is affected (RDF is XML, but by XML I presume you meant
the XML format used for moving).

XML and RDF may have mechanisms for versioning, in which case we could get away
with bumping the version number on our schema (or coming up with a version in
the first place if we didn't have one before).

The new JS version of bug lists will be affected.

Comment 4

[Myk Melez [:myk] [@mykmelez]]

versions.value and milestones.value should become "name" to match components.

Comment 5

[Bradley Baetz (:bbaetz)]

Right, and we should be using ids. But they will become custom fields, so for
the moment, lets not bother.

Comment 6

[Gervase Markham [:gerv]]

bbaetz: are you saying we shouldn't bother with any of this, or just the last two?

And I don't think it's at all clear that our current fields will become custom
ones; it depends on the performance hit of enabling custom fields.

Gerv

Comment 7

[Bradley Baetz (:bbaetz)]

Just the last two.

True (re the perf stuff), but we'll have to try it and see.

Comment 8

[Christian Reis]

Ah, this is precisely what we were hoping for in bug-bugzilla. Cool.

Comment 9

[Myk Melez [:myk] [@mykmelez]]

kiko: what is "bug-bugzilla"?

Note that what I really want to fix are the external names.  We can cope with
bad internal names, which a limited number of people will ever see, and which
many of us are already used to, much more than we can cope with bad external
names, which we hope will be adopted widely and broadly (and which haven't seen
much adoption yet so are still changeable without much pain).

Comment 10

[Christian Reis]

Myk: It's a standalone bug submission; we implemented it over at bug 220724. It
used HTTP POST to contact the server, and we provide a mapping from "sane" names
to Bugzilla form variables.

Comment 11

[Myk Melez [:myk] [@mykmelez]]

I'm having second thoughts about this work.  It turns out to be more complicated
than I thought at first.  It's not just a question of translating from one name
to another when generating output (bug lists, bugs).  We would also need to
translate names in search criteria that clients submitted.  And these
translation tables would be different, since the one for output would need to be
in field-descs.none.tmpl for localizability while the one for input would have
to be in code.

So there's the issue of keeping those two tables in sync.  Then there's the
question of supporting both old and new names in both output and input.  And
differentiating between search fields (attachment_data), bug list columns
(attachment_data), and bug data (bug.attachments.####.data).

There's also schemas to consider, and reading the RDF schema specification
convinces me that it is unsuitable to our task, not the least of which because
it is descriptive but not prescriptive (so cannot be used to specify exactly
what Bugzilla's RDF output will and won't look like).

This may still be the right thing to do, but at this point it looks like more
trouble than it's worth.  Putting it off.

Comment 12

[Gervase Markham [:gerv]]

So are we changing the RDF to match the database names, or are we leaving them
inconsistent?

Gerv

Comment 13

[Myk Melez [:myk] [@mykmelez]]

The RDF was already changed to match the database names last December in bug 176461.

Comment 14

[Christian Reis]

Yeah, we're worried that the external names are cryptic and/or loaded with
historical bias. Updating summary and alias to sanefields.

Comment 15

[Thomas Thurman]

*** Bug 129076 has been marked as a duplicate of this bug. ***

Comment 16

[Dave Miller [:justdave]]

Reassigning bugs that I'm not actively working on to the default component owner
in order to try to make some sanity out of my personal buglist.  This doesn't
mean the bug isn't being dealt with, just that I'm not the one doing it.  If you
are dealing with this bug, please assign it to yourself.