[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         | Ralf Lang (B1 Systems GmbH) <lang at b1-systems.de>
  Summary            | Add an undelete feature for Kronolith Events
  Queue              | Kronolith
  Version            | Git develop
  Type               | Enhancement
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Ralf Lang (B1 Systems GmbH) <lang at b1-systems.de> (2012-06-01 17:42) 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
* 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