On 21 March 2012 12:56, Steve Bennett <stevag...@gmail.com> wrote: > 1) We can fix this, but it's hard to prevent it coming back when new > features are built. I've probably written such bugs.
Mumble grumble unit testing. > 3) I still think we should do this. We have a responsibility to not > mess up the database. Saying "well, we should avoid writing bugs" > isn't addressing that: we should both implement this failsafe > mechanism, *and* avoid writing such bugs. Well, I'm not sure I agree on this one. If it was a truly awful thing to do, the API would prevent it. Given that it's not truly awful, it's not something to worry about too much. It's not messing up referential integrity, it's just something unexpected and, at the moment, seemingly useless. Furthermore, handling it at save time is, to me, the wrong thing to do. What do we do when we find our data has an issue? Alert the user? Silently swallow it? Neither is a good thing. Should that way be deleted? Should a node be re-inserted? What did the mapper mean to happen? We can't tell. Finally, in other projects I follow the convention of "don't code defensively", as described at http://www.erlang.se/doc/programming_rules.shtml#HDR11 and elsewhere. The save code should "trust" that the data is good. If the data isn't good, whatever made it bad should be fixed. Otherwise it's turtles all the way down - should the save code check the ids are actually numerical, just in case, should it do x, y or z, just in case? So the answer is that the input should be checked, somewhere in the controller code, and then it should be trusted. Anyway, mumble grumble unit testing. When we find out what's the trigger, for the love of god someone should help me write the unit test so that when it's fixed, it stays fixed. Thanks, Andy _______________________________________________ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
