[contestms-dev] Re: Separate users and tasks from contests
- From: William Di Luigi <williamdiluigi@xxxxxxxxx>
- To: contestms-dev@xxxxxxxxxxxxx
- Date: Wed, 13 Aug 2014 23:22:31 +0200
On Tue, Aug 12, 2014 at 7:55 PM, Giovanni Mascellani <
mascellani@xxxxxxxxxxxxxxxxxxxx> wrote:
> My main reason is that you have to add another layer of logic in the
> persistence logic and in everything else that uses tasks and contests. I
> see no real reason to introduce this new complexity, as it hardly
> describes anything that is really worthy keep tracking of.
>
Consider that, by making CMS more "flexible", it could be easier to develop
plugins (when a plugin system will be available).
I consider CWS' task to correctly present tasks to the contestant. Thus
> I find it proper to let it filter out tasks that a certain contestant is
> not supposed to solve. Moreover, I stress that the one you mention is
> TTBOMK the only case ever happened that had this strange needs.
>
That may be the only case I witnessed but the "two contests sharing some
subset of tasks" scheme is actually very popular. It is found in TopCoder's
SRMs and Codeforces Div1+Div2 rounds. I wouldn't be surprised if someone
out there (who is used to this kind of contest) would want to use CMS to
organize a contest using such a scheme.
On Tue, Aug 12, 2014 at 6:21 PM, Stefano Maggiolo <s.maggiolo@xxxxxxxxx>
wrote:
> No, I'm *not* proposing something like:
> - creating task A;
> - cloning A to B;
> - changing field alpha of B (no change to A.alpha);
> - changing field beta of A (this change B.beta too);
> - changing field alpha of A (conflict, decide what to do).
>
> I'm proposing something like:
> - creating task A;
> - cloning A to B;
> - changing field alpha of B (no change to A.alpha);
> - changing field beta of A (no change to B.beta);
> - changing field alpha of A (no change to B.alpha);
> - you can see the differences between A and B in a "graphical diff tool"
> and move field values from A to B and vice versa with one click.
>
> This last point is what I think it would be useful for datasets too (it is
> now difficult to see what are the differences between datasets).
>
I think this might be OK. Anyway, what do you think about Luca's proposal?
It seems similar to this. The only difference is that he proposes to clone
only the dataset when associating a task to a contest (storing dataset_id
in the TaskContest table). It seems equivalent, but cleaner. It would,
however, require the task-contest separation.
--
William.
Other related posts:
