Closed kvesik closed 1 month ago
I'm going to merge the workaround from branch 242 into main, so that other users can let me know if it comes up for them. But this issue should remain open.
I think confirmhighestID()
should not be called when serializing an empty corpus since there would be no entry IDs.
I'll just go ahead and add a conditional like this.
if len(self) > 0: # self being Corpus
self.confirmhighestID("save")
(...)
closing; does not seem to have persisted into current use
I was attempting to add a sign to the AFTERNOON_v1_ALARM corpus and discovered that the first new sign added does not appear in the corpus list (nor does it appear to get added to the set of signs at the back end either) BUT the second, third, and later signs do.
To reproduce:
I have only encountered this bug so far with one corpus (though two different versions of that corpus):
Upon closer inspection, it appears that this corpus contains 10 signs, with entry IDs 0001 through 0009, and 0011. Perhaps another sign was originally entered and then deleted? At any rate, the numbering is not the problem. The problem is that the serialized (saved-to-file) version of this corpus has its "higest ID" recorded as 10 instead off 11. So when I attempt to add a new sign, the highest ID is auto-incremented to 11, but the new sign is not added (I assume due to some conflict with there already being a sign with ID 11... though I don't see any errors thrown so ???). But once I go to add a second new sign, the highest ID is auto-incremented to 12, and the sign is successfully added to the corpus, as are any following ones.
I'm not sure whether this is a quirk related to this corpus specifically, or if there was some issue with how signs were being deleted or added at some point (if I create a new corpus now, delete a sign, and save, then reopen and attempt to add a new sign it works as expected). For the time being, we can use a workaround that consists of:
... But we should also...