"rename integrity" on the activity table?

[Joel Peshkin]

Gervase Markham wrote:

> Joel Peshkin wrote:
>
>> So, I implemented an update in checksetup.pl that converts the 
>> existing bugs_activity records to match the new schema and then 
>> deletes the unused and absent field from fielddefs.  This is fairly 
>> easy.
>>
>> However, this starts an interesting precedent (which would be very 
>> important to anyone using the activity log to generate reports) where 
>> we would expect the activity log to accurately reflect the activity 
>> even across more structural changes.
>
>
> I would expect the log to tell the user what happened - exactly how it 
> stores the information is not relevant. If it's easiest for us to 
> change  the table format and store it differently, let's do that. I.e. 
> do what you said you were doing above.
>
> Gerv
>
> -



Ok... so Here's the proposal.....

Storing the groupset bitmask number in the activity log instead of 
listing the group names is inconsistent with the way everything else 
works and it makes no sense at all after the groupset is replaced by a 
map anyway, so the history of
groupsets should be converted to eliminate the groupet numbers at the 
same time as the groupset is eliminated from the DB.

This will make group changes look just like changes to dependencies or 
CC lists, with a list of items added or removed and queries and buglists 
referring to old historical changes will treate it just like dependency 
changes. (including bug 163362)

Doing this catches groups up to being just as good and just as much of a 
mess as other history items.

At this point, the history is accurate unless something changes name. 
 Any group change made prior to a name change for that same group that 
is already in a DB is already lost/confused information.  Any group 
change made already is in jeopardy of being lost until activity logs get 
integrity just as is true of product, asignee, cclist, and component 
changes now.

To solve this, we would need to roll through the history whenever doing 
a rename.  The simplest case of this is in cases of a product or group 
rename (ignoring deletion and resurrection for now)

UPDATE bugs_activity SET removed = 'newname' WHERE removed = 'oldname' 
AND field = getfielded('product')
UPDATE bugs_activity SET added = 'newname' WHERE added = 'oldname' AND 
field = getfielded('product')

When a product or group is deleted, we may want to prevent it from being 
changed further...  That's a bit strange, but we could do something like....
UPDATE bugs_activity SET removed = 'DEFUNCT(name)' WHERE removed = 
'name' AND field = getfielded('product')
UPDATE bugs_activity SET added = 'DEFUNCT(name)' WHERE added = 'name' 
AND field = getfielded('product')

So far, so good (we can debate how to mark the defunct items later)... 
This should work for email addresses, products, groups, platforms, 
priorities, etc...

For components and versions, this is a bit trickier...  say we have a 
component "foo" of product "a" and a component "foo" of product "b" and 
we rename a/foo to a/bar while leaving b/foo alone.....

We need to
UPDATE bugs_activity SET removed ='bar' WHERE removed='foo' AND field = 
getfieldid('component') AND  **this**
(ditto for added)

Where **this** means that either the next change to product AFTER this 
entry removed "a" OR (there is no later change to product AND the bug is 
still in product "a")

This is a bit hairy, but only has to be written once and executed rarely.  

If we do this properly,  then the acitvity logs will start to be 
accurate even through renames and schema changes.  This is vital if we 
want to do good reporting.


-Joel