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.. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
