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
