bdenckla/vsource — Issue #10: judgments go to their own table, not the user table
Author: bdenckla
Created: 2011-11-04 17:17:38+00:00
State: open

Or, another way of putting it, is that judgments are unique to a piece of evidence, not unique to a user.

For example what if a piece of evidence is judged as being for the fafsa itask and then a judge goes back and revises it to be for the reg-sat itask. Then, if judgments are made upon users, without some tricky logic and db state to prevent it, the user will appear to have completed both the fafsa and reg-sat itasks.

Also, as usual the reward criteria for the app itask complicates things since you need to complete 2 apps to get the reward. So, this creates problems even without a revision scenario like I described above. It would be hard to record an app itask judgment into a user record because we would have to decide "which" app itask it is. I.e. there would be an app-1 and app-2 field. Or there would simply be an app count but then we couldn't refer back to which piece of evidence was judged to be a completion of the itask.

All of this becomes much simpler if judgments just live as records in their own table. To some extent it pushes the complexity elsewhere, for example making the query for "show rewards to do" complicated, but that is my problem and I think I have solved it.

It is worth asking, zooming out to the big picture, how much your code should emulate the real logic underneath, and therefore how much it should worry about stuff like this. So I may be making too big a deal of this. But I think it is easy in this case to make your code more real.