So thats a really good question. We have to replace report['id'] in the copy we write, or else its not visible to someone reading the report later.
I've noticed a defect in the branch - we don't inherit the id with the lognamer based id allocator - I'll fix that (we won't use the combination, but someone may) and push that up. I had the thing in my head that I needed to eject any existing id before hashing, but you're quite right, we can hash with an existing id in there and its no less unique - though if we are not inheriting the id: - someone publishes the same oops twice with differing ids, we'd end up writing it twice to disk - big deal - publishing the same oops with no id in it would behave as we do today - publishing different oopses with the same id will behave as we do today I'll have a fiddle when I fix the defect and see how it looks. Thanks, Rob -- https://code.launchpad.net/~lifeless/python-oops-datedir-repo/0.0.9/+merge/78793 Your team Launchpad code reviewers is requested to review the proposed merge of lp:~lifeless/python-oops-datedir-repo/0.0.9 into lp:python-oops-datedir-repo. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-reviewers Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-reviewers More help : https://help.launchpad.net/ListHelp
