[contestms-dev] Re: Separate users and tasks from contests
- From: Stefano Maggiolo <s.maggiolo@xxxxxxxxx>
- To: contestms-dev <contestms-dev@xxxxxxxxxxxxx>
- Date: Tue, 12 Aug 2014 08:39:13 +0100
Hi,
thanks for your work (and nice to interact with Lorenzo again too)!
Yes, separating users and contests was a long-standing wanted feature. I
don't think there is much advantage for 2-days contests, where we are more
or less ok with the RWS model. I wanted this for training settings were you
may have many contests and you want to do something for which you need to
connect users in different contests, and that is smarter than what RWS does
(which is just a sum). I feel that we could do much more for these settings
and this goes in the right directions.
About tasks, I'm not so sure of the advantages, I have the feeling that
your use case is not shared with many people. I'm not even deeply against,
if not for the work required.
I tried looking at your branch but it was kind of difficult to understand
the state, so I have a few questions.
- For both users and more importantly for tasks, which fields are dependent
on the contest? When I was working on the Italian repo, one observation was
that often it doesn't make a lot of sense to reuse the same timeouts for
old tasks as new hardware and better compiler make the same program much
faster.
- Are you thinking of porting back your PWS? As I understand it's not under
discussion here (and it would require another discussion).
- What timeframe do you expect to finish all of these changes? Even though
I didn't tell anybody yet, I'd like CMS to follow a best-effort semestral
release cycle, with heavier stuff going in in the release ending in July,
and milder stuff in January. Do you think that this is "mild" enough and
would be implemented fast enough to get in in January?
-- Stefano
On 11 August 2014 20:48, William Di Luigi <williamdiluigi@xxxxxxxxx> wrote:
> Hi,
> currently, all users and tasks are tied to a single contest. The idea of
> separating users from contests seems to be already "accepted", as there are
> clear benefits to it. For example, the ITA1 contestant named "A B" having a
> particular photo.jpg **should** be the same person across the two
> contests (i.e. "IOI day1" and "IOI day2").
>
> However, since I've been involved (along with other people) on
> a "training-oriented" CMS fork, I also see benefits in the separation
> between tasks and contests. I'd like to allow to (authorized) users to set
> up training contests (that is, CWS instances served within the main
> website, which is PWS=PracticeWebServer) by simply "choosing" what tasks to
> use from the main archive, or by creating some tasks. For example, a user
> could create a task and keep it untied from any contest (thus invisible)
> until he decides to use it.
>
> I understand that CMS has not the need nor the duty to do that separation,
> but I think that it would benefit as well from that.
>
> Once users are separated from contests, the contest importing (or
> exporting) process has to be adjusted. When ioi_day1 is imported there are
> no users yet in the DB, so you will either:
>
> 1. Import the contest (and create UserContest participations)
> "forcing" the creation of the needed users (not a very nice approach),
> or...
> 2. You will create the users first and then import the contest (or,
> indifferently: import the contest with zero users, then create the users,
> and eventually associate them with the contest).
>
> I think that the latter approach is cleaner (it doesn't enforce an order
> between contest creation and user creation) and more maintainable. Overall,
> I'd say that it makes sense to separate the "creation of users" phase from
> the "creation of contest" phase.
>
> Now, if users gets created independently from the contest, it makes sense
> to use a loader to create them (so BaseLoader will be split in two
> different interfaces: UserLoader, ContestLoader, each of them specifying a
> get_user() or get_contest(), and how to check if the user/contest has
> changed). For the **italy_yaml** format, this means that each users will
> be stored in its own folder (like contests) with its own user.yaml file
> (specifying first_name, last_name, email...) and maybe a profile.jpg.
>
> If the task's importing process becomes independent from contest's as
> well, we would simply have one more interface: UserLoader, TaskLoader,
> ContestLoader (actually, when you have users and tasks on the DB, there is
> no real need for a ContestLoader... for example, an interactive
> cmsSetupContest prompting "which of these tasks and users do you want to
> associate?" would do).
>
> Also, the current setting for contest dumping (and reimporting dumps)
> would have to be changed: it's difficult to export ioi_day1 and ioi_day2 in
> two different dumps (since they share their users), so it will be necessary
> to either dump Users separately or to just redefine the current meaning of
> dump from "dump of a contest" to "dump of a database" (I'd vote for this
> one). In both cases, separating Tasks doesn't "add complexity".
>
> The expected outcome that I see is CMS handling user/task/contest creation
> processes independently, with some benefits:
>
> - Easier testing
> - It's easier to mock components if everything is as modular as
> possible
> - Easier contest setup
> - For italy_yaml: it's not compulsory to have tasks as subfolders
> of the contest folder: you can keep them wherever you want because you
> will
> import them independently; the same thing stands for users
> - For other formats: if you have a TaskLoader but don't have a
> UserLoader because, maybe, you are used to keep only tasks (and create
> users with a different process) you can "borrow" another format's
> UserLoader
> - cmsReimporter disappears
> - Why reimport an entire contest when you can reimport exactly what
> you changed? (well, actually **italy_yaml** checks if a task has
> been changed before importing it... this check would still be handy, to
> "warn" contest admins trying to reimport an unchanged task, but would
> become unnecessary). Also, in "my" use-case, even checking if tasks have
> been changed it's still quite annoying (we have about a hundred tasks).
>
> What do you think?
>
> We started working on this here
> <https://github.com/wil93/cms/commits/decouple_user_contest>, I added a
> cmsAddTask utility (thus completing the "family" of cmsRemoveTask,
> cmsAddUser, cmsRemoveUser). I think that we have done almost all the needed
> DB changes, apart from Submission (on which we are working now). There are
> some things left to do such as finishing to port CWS and AWS to the new DB
> (CWS should be already in good state, I think) and decide how to handle
> dump export/import.
>
> --
> William.
>
Other related posts:
