Comment 15 for bug 28459

2009/6/18 Graham Binns <email address hidden>:

>> It's not hackish at all IMO, it's a pretty standard way of working with
>> stateless clients.
>>
>
> To clarify, I feel that it's hackish compared to using the changelog
> (were it reliable enough, which I'm not certain that it is right now)
> plus a simple timestamp (marking when a user's interaction with the bug
> began) to work out what happened when and which changes collide with
> each other. Keeping a hash of the old state of the bug when we should
> have a good record of it anyway (or at least a cumulative one) in the
> database.

There were two different proposals using hidden fields (at least).
One was to store a hash. Mine, which I still think is simple and
non-hacky, is to keep a second copy representing the original state of
each field:

  old_importance=medium importance=medium ---> no change
  old_target=None target=1.16 ---> change target to 1.16

Then you can see which fields they intended to change. If there was
no delta, don't change that field. If there was, do change it. For
bonus points, if the current value at the time of submission is not
the old value, you can tell the user about the conflict (maybe by
showing a notification bubble) - I'd probably apply the change anyhow.

I don't see how indirecting through the database to get the old values
helps because the amount of data is pretty small.

--
Martin <http://launchpad.net/~mbp/>