Hi. Il 11/08/2014 21:48, William Di Luigi ha scritto: > 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. This is not a very relevant argument to me: the task of setting up the content of the database before the contest does not belong to CMS, but the relevant importer tool. You can choose the order you want to develop your contest. At some point you are ok and your importer does the job of translating whatever format you like to the one CMS uses. Moreover, the fact that you can create things in the order you want in the database is unrelated to the fact that users can be shared by more than one contest. Actually, you can already create a contest with no users and then add the users; and deciding that Users.contest_id may be nullable (which think I do not oppose) you can also create a lot of users, then a contest, then associate the users to the contest. This has nothing to do with sharing users between contests. To me, the real reason to have shared users is because that's just a representation of reality: the same user is actually playing two different contests, and it is reasonable to keep track of this identity. While this was not one of the main use case we had in mind when we designed CMS, it is now sensible, for example in your training site, to introduce this new piece of information in the database. This is, as I already mentioned in my previous email, the same reason to say that we probably don't want to do the same with tasks: the same "task" in two different contests actually are two different tasks, not the same task referred twice. When you modify one of that, you expect the other not to change (except exceptional cases, but this is trivial). > 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. This splitting of the importing interface (which probably has quite some merits) can be done anyway, independently from how users are represented in the database. > 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 dump format is actually already a "dump of (a part) of the database", with just the requirement that there is exactly a Contest object, that it is number 0 and that all the other objects are "descendants" from that Contest. These requirements can (and in my opinion should) be dropped without much harm, since there is no real reasons for them. Then I think that very small changes are needed to be able to dump more than one contest in the same file and make sure that object references are preserved in the dump. > The expected outcome that I see is CMS handling user/task/contest > creation processes independently, with some benefits: > > * Easier testing > o It's easier to mock components if everything is as modular as > possible This is not a real problem. Creating mock contests is the least part of testing. We already have tools to do that. > * Easier contest setup > o 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 Again, this is a problem of the italian_yaml format (one of the many, actually). But solving this problem should not require a change of the CMS data model. If a new tool must be developed in order to update a single task, then that's fair, but you don't need to change CMS for that. Or maybe I'm not seeing the problem. > o 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 Definitely, separating different stages of loading is probably a good think (although unrelated to sharing users between contests). > * cmsReimporter disappears > o 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). Well, to me the point of a reimported is just that of being lazy and asking the reimported to mind about the merging details. In conclusion, I'm in favor to implement users sharing between contests (although for apparently different reasons from you) and I'm mostly against sharing tasks. I'm also in favor of splitting the importing interface in different logical pieces, but I consider that to be independent from users (or tasks) sharing. I don't think that inefficiencies in import formats are good reasons for changing CMS data models. Giovanni. -- Giovanni Mascellani <giovanni.mascellani@xxxxxx> PhD Student - Scuola Normale Superiore, Pisa, Italy http://poisson.phc.unipi.it/~mascellani
Attachment:
signature.asc
Description: OpenPGP digital signature
