[Tickets #11187] Re: Add an undelete feature for Kronolith Events

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/11187
------------------------------------------------------------------------------
  Ticket             | 11187
  Updated By         | Jan Schneider <jan at horde.org>
  Summary            | Add an undelete feature for Kronolith Events
  Queue              | Kronolith
  Version            | Git develop
  Type               | Enhancement
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Jan Schneider <jan at horde.org> (2012-06-01 17:56) wrote:

>>> Should undeleting be implemented driver-agnostic (through added
>>> details in the horde_histories delete action or through a specific
>>> undo table) or should it make use of backend specific features and
>>> only be implemented for certain backends?
>>
>> Good question. It would probably be easiest to implement on the
>> driver level, because it would only require adding a flag, and we
>> won't take the risk of losing any event information.
>> This could be tough or even impossible with some drivers though.
>> A driver-agnostic solution would make this work in all drivers,
>> though it still won't work if using a shared backend with different
>> clients. OTOH those other clients wouldn't recognize the custom
>> backend flag anyway, so this probably shouldn't count as an argument.
>> And we probably *do* want those events to disappear for other
>> clients, even if we allow undo.
>>
>> Since the reason for using a different backend than SQL might be to
>> not rely on an SQL server, those events shouldn't go into a separate
>> table. Pondering all arguments, I think storing them in the history
>> backend could be the best solution. This would also allow this to be
>> implemented easily for other applications too.
>>
>>> How should undelete deal with the sync-relevant history entries?
>>
>> For synchronization (or any other external client for that matter),
>> this would be a regular deletion. Undeleting would not be reversing
>> the deletion, but re-adding the deleted event.
>
> I've been thinking a while about this and I mostly agree.
>
> * Histories is a sufficient undelete store - we already track  
> deleting there for sync purposes and I could expand/modify the work  
> on remembering attributes on change. This allows a backend-agnostic  
> implementation.
> * We currently only have sql as a history backend but probably  
> indexed key stores or nosql dbs like couch or mongo could be added  
> if somebody needs/pays for this.
> * Undelete/Roll Back/Revive should probably be optional

I don't see a good reason why we should make this configurable. If the  
history backend is available, we should support undelete. Unless  
someone comes up with a really good reason to separate one from the  
other.

> * A deleted event should disappear from backend, reviving should add  
> a new version of the old data
> * We don't care about external clients. If horde is in the backend  
> chain, we will be able to save undelete data. Undeleting can only be  
> done through horde ui