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 > > 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 >
Attachment
Watch this ticket

Saved Queries