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

Search Results: 374 of 574 [ <<First <Prev Next> Last>> ] [ Return to Search Results ]

* Your Email Address
* Spam protection	Enter the letters below: . . ..__..__ .___. \| \| \|[__][__) _/ \|___\|__\|\| \|[__)./__.
Comment	>>> 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
Attachment
Watch this ticket

Saved Queries