[cosmo-dev] [proposal] Bug 10442 - Deal with Bad Data in Sensible Way

[Matthew Eernisse]

Bobby,

If by, "on the server," you mean "at the point of creation," off the top 
of my head, there could be a couple of issues with that:

1. We may think we've covered our bases on the server, but there will 
still likely be data (particularly from other clients) that gets through 
unanticipated holes in our safety checks and breaks the Web UI.

2. After stuff gets saved, migration scripts may still make changes that 
break things in the UI in unanticipated ways.

I think doing it server-side might indeed make more sense, esp. from a 
perf standpoint. I guess we could also consider doing it on the server 
when we pull the data out.

But it might also be worth considering that the client itself has the 
best idea of what data it expects, and what format it expects things to 
be in.

The scope is definitely bigger than negative durations.

I think the ideal would be that the Web UI could still load even if the 
data it's handed is wonky in some way, and we'd alert the user that 
there was a problem -- possibly even give them the summary/title of the 
defective item, and possibly give them the option to nuke it if it's theirs.

This is definitely a hard problem. We don't want some client-side (or 
server-side, for that matter) solution that cripples perf.


Matthew


Bobby Rullo wrote:
> It's not clear to me how to proceed with this bug.
> 
> Firstly, what is the scope of this bug? Is it "bad data" in general? Or 
> just these negative durations? If bad data in general, what constitutes 
> bad data?
> 
> What should be done if we find bad data? And when? Should we filter each 
> item from the server for bad data and pop up ui as they come in?
> 
> In any event I propose that we do nothing on the client side. It seems 
> like the work is much easier to do on the server - disallow specific 
> things like negative durations when they are created by returning an 4xx 
> Http status. It seems silly to allow the data on the server and then put 
> the logic to force a change on the client.
> 
> Bobby
> 
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
>