Move graphing into the DB




17 years ago
5 years ago


(Reporter: gerv, Assigned: gerv)


Dependency tree / graph


Working on MattyT's Customised Resolutions branch, CUST_RES_BRANCH, I need to
move charting into the DB so it works again.

MattyT: could you please point me to documentation/bug comments about how Cust
Res works? What tables it uses, etc.

Resolutions table.  Should be self explanatory except restype which i doubt you
need to bother with.  You need to use IDs to handle renaming.

I suggest you're interested in @::queryable_resolution from the versioncache for
your resolution list.

It would be really nice if resolution deletion didn't do the deletion of data
for that resolution.  I don't think it should.

One implementation I was thinking is to maybe have a third 'zombie' state for
the inactive field on resolutions.  Resolutions stay here until the graphing
data disappears for that resolution because it reaches the cutoff (is there

The more obvious alternative is to put a name for each resolution id somewhere.
Priority: -- → P2
Target Milestone: --- → Bugzilla 2.16
Just a quick progress update. I have it importing legacy data, and I have the UI
for choosing which charts to plot and plotting them. 

Next up is defining new charts.

OK, I am blocked on this bug by the query.cgi redesign - bug 98707. I can't do
the UI for adding charts until that gets checked in, so I can modify it to allow
chart addition. Doing the work on the current query.cgi would just mean a
reimplementation, and doing it on the new one would make it hard to keep the
patches disentangled.

So, matty - review bug 98707 :-)

Depends on: 98707
Blocks: 16009
How is the chart bug selection stored in order to respect renaming, etc?

Is anything being done to maintain the current nice feature where you can set up
a chart condition that applies to all products, or do you have to manually add
one for each product?
It doesn't appear that this is going to make it for 2.16, so we might start
thinking about merging stored queries and charts.  By this, I mean when you
store a query you decide whether or not charting information gets recorded.

To start with we could introduce a systemqueries table (bug #69000) in a similar
way to the current personal stored queries table.  Then we would have a column
on systemqueries that indicated whether it is charted.   A table would hang off
it called systemcharting with the historical data.

Allowing charting for personal stored queries would then be a future

System queries that are charted could never be user-relative (bug #41651).
We are currently trying to wrap up Bugzilla 2.16.  We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut.  Thus this is being retargetted at 2.18.  If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
Blocks: 94534

Comment 7

17 years ago
I didn't find the existance of until around October. My company
had already been using bugzilla for several months before that. With this
refactoring a charting, will I be able to create charts that go all the way back
to day 1 of our bugzilla installation? If not, should I create a new bug for
this feature request?
This will happen as part of 16009, which I am now actively working on.


*** This bug has been marked as a duplicate of 16009 ***
Last Resolved: 16 years ago
Priority: P2 → P3
Resolution: --- → DUPLICATE
clearing milestone on all DUPLICATE/WONTFIX/WORKSFORME/INVALID so they'll show
up as untriaged if they get reopened.  "Jiminy Cricket!" for the filters (and I
don't care if it's spelled wrong ;)
Target Milestone: Bugzilla 2.18 → ---
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.