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

bugs at horde.org bugs at horde.org
Fri Jun 1 15:42:47 UTC 2012


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





More information about the bugs mailing list