Split out some Import Data pages

[philipbelesky]

Problems:

• The conflicts pages in particular has a huge response time (due to rendering all the foreign key fields across all values) at large tournaments. It risks timing out or severely delaying other requests
• When the list of conflicts gets very long the space to add new items is way down at the bottom of the page and is potentially overlooked or at least annoying to get to

Proposal:

• Separate out the Edit and Add pages into distinct views for venue categories/constraints and conflicts
• The Add pages can render the full list of options for each addition (since there will be at max 10 extra options)
• For the Edit versions of the Conflicts pages the conflicter/conflictee fields shouldn't be big selects — they can just show the existing data inline without the option for editing (only deleting)

This does mean that those pages essentially become 'delete' pages rather than edit pages, but I'm not sure the use case of going in an editing a conflict to be a different person ever really happens?

[tienne-B]

Would #590 be another possible solution to this?

[philipbelesky]

Hmm, I'm not sure if it would work given the time is spent within the templating system. There might be a way to pass that off. Not sure.

However to the extent that #590 is implemented I'd prefer it to actually be used for actions that are asynchronous from the perspective of the user — i.e. for in-page actions (like allocations) or actions that are 'fire and forget' (like email). In this case splitting out the views makes sense (I think) from a UX perspective so pushing the render on to a task runner wouldn't help with that angle.

[czlee]

The conflicts and venue constraints pages are pretty primitive, because I put them in as a quick job to make mass additions a little easier (relative to the Edit Database area). Don't take the status quo too seriously—I'm pretty sure there should be ways to make these way faster without splitting pages up, and I think if we can do this without separating "add" from "edit" that would be preferable. That said, I agree that it's not really necessary to provide an "edit" function at all, i.e. that a "delete" function should suffice.

Could we leave "delete" and "add" on the same page, though? Sometimes you will want to edit a conflict to correct mistaken identity, and I don't think deleting then adding is too much to ask of a user (it's only two fields), but it'd be easier if it were on a single page.

[philipbelesky]

Yea, I wouldn't mind keeping them on the same page. Although I think the case specified of deleting and adding being made easier might need to be balanced against the general task of adding being less convenient by having to scroll all the way down to the end of a long list.

[czlee]

Hmm, true, that's a fair point.

[czlee]

Actually, I can't seem to reproduce the huge response time. As in, the conflicts pages load pretty quick for me (for bp88team), but it's even more strange in that the querysets that produce the dropdown fields don't seem to show up at all in the Django debug toolbar's SQL summary, and I'd expect them to appear at least once. Do we know if this is a duplicate SQL queries problem, or something else?

[philipbelesky]

Sorry, should have clarified: the problem is not duplicate SQL queries but rather the render time, I assume due to the fact that each row contains two select elements with all possible values — e.g. all adjudicators and all teams in the case of adj-team conflicts. At a tournament with 100 adj-team conflicts rendering takes around 40 seconds for me (running locally).

I don't see the SQL queries showing either. So perhaps the render time is masking the SQL loop; or whatever method the forms widget uses doesn't report them to Debug Toolbar but is still slow regardless.

[czlee]

Okay, I'm definitely reproducing this now. The problem is all client-side, right?