Uncomment doesn't remove comments

[cbaakman]

When I wanted to replace a comment for 50 entries by a different comment, I put these 50 entries in a whynot syntaxed textfile in the uncomment directory (for the comment to replace) and the comment directory (the new comment to give them).

The annotater placed the new comments, however the old ones were not removed. Though the annotater reported it so.

[jonblack]

The concept of having to place a file in a folder to comment/uncomment manually is really awkward. We should move away from this and instead introduce an API (see #44).

@drlemmus Can you explain why some entries need to be manually added to comment and uncomment? Why aren't they picked up automatically when crawling the databanks? (I'm have a gap in knowledge here and it'd be nice to fill it).

I'm also wondering what happens when an entry is added to comment and processed, and then that entry gets picked up later on by the crawler/annotator. Since the annotator will have a more up-to-date version, the manual changes will be overwritten. Is that always correct?

[drlemmus]

The problem with an API that I didn't mention before is that there need to be backups of the database, because there is no 'paper trail'. The fact that we lost the database now and we still have the comments in the comment/uncomment directories to restore it shows that it is convenient to have such directories. By the way, restoring the comments should be a priority and crawling the databanks should be a priority. We cannot test if the databanks are not indexed yet.

@jonblack If the reason why an entry cannot be made is caused by a technical difficulty that was not know a comment may need to be added manually after analysis of the input data. That is why we need to manually add comments.

Now if a previous problem is overcome in a new version of the software making the entries (or by remediation of the input data), the missing entries with a particular comment can be made. In the original idea, we would only try to make these if there was no comment saying that the entry cannot be made. That is, new entries are made if they are of the 'missing-unannoted' group, so first the existing comments had to be removed.
However, we are currently working with skip lists rather than directly with the info administrated in WHY_NOT, so the above reasoning does not apply fully. Instead we can now make entries by removing them from the skip list (note that this is an extra step that requires access to the skip lists). Now if the entries are made, they move from 'missing' to 'present' and any existing comments are trashed. However, if there are entries that cannot be made for a different reason a new comment and the existing comment are stored. At this point however, the existing comment is invalid and must be removed. That is why we need the uncomment mechanism.