[Chandler-dev] Re: Discarding bad data?

[Andi Vajda]

On Thu, 1 Jun 2006, Heikki Toivonen wrote:

> Is it possible for Chandler to degrade gracefully, to discard bad data
> instead of even failing to start in case of bad data in a few items?
>
> We have plans to discard UI data, but I am thinking beyond that. What if
> due to some Chandler bug the note you just created was created badly and
> next time you try to look at any note, all you get is tracebacks (or
> perhaps Chandler doesn't start at all)? Wouldn't it be nicer being able
> to scan the repo, and discarding bad data? You'd have to tell the user
> that this just happened, and perhaps dump whatever could be gathered
> from bad data into an emergency data dump.
>

The problem with this is that at the repository level, there is no such thing 
as generically bad data. Either the transaction got committed and the data is 
good, or it didn't and the data got lost. If very low-level data is bad such 
that a Berkeley DB data file is corrupt then the Berkeley DB tools can kick in 
to try to repare it. This needs hand holding and is non-trivial.

If there is a bug in the repository that would let bad data be committed such 
as a dangling ref, there could be code added that recovers from them. I've 
been thinking about adding that.

If, however, there is a bug in the app that causes data that is good from the 
repository's standpoint but bad from the app's standpoint, then the app needs 
to detect and recover from that.

But there is something else that the repository could do: given that the 
repository is versioned and is keeping all versions of items (even deleted 
ones) until you purge it of its old versions, I could add an API to let the 
user tell the repository to discard the most recent version(s) committed until 
the app is happy again. This would be a great addition to Bryan's dialog, a 
user controlled rollback utility.

Morgen suggested this a while back and it's on my todo list.

Andi..