Open Alex-Jordan opened 11 months ago
Probably the only fix would be to add a check when a course is created that ensures that the course id will not cause a conflict with other tables in the database, and if so refuse to create the course.
This is a consequence of the table structure of webwork2, and there really isn't a fix that would allow full freedom to choose course ids without using a relational database structure like what webwork3 will use.
Note that there are other conflicts that can occur as well. For example, create a course by the name "first", and then try to create another course with the name "first_problem". The "first" course will have a table named "first_problem_user" created, and creation of the "first_problem" course fails with errors, because that table already exists. Furthermore, the "first_problem_user" table gets deleted in clean up from that failure. Thus breaking the "first" course.
It seems that webwork2's table structure using the course name for its database tables is really quite fragile.
If we wanted to avoid a complete overhaul, is there a character (not underscore) that is illegal in course names, that could more reliably separate the course name from the table type? Like having first&problem
, first&problem_user
, and first_problem&user
?
That might work. Then OPL&problem
would not conflict with OPL_problem
either. Of course, assuming &
works for this (or that some other character can be found that does).
An upgrade path for existing courses and figuring out how to unarchive courses would be challenging.
If you create a course with ID "OPL", then first, it fails. It fails because the OPL tables in the database already include
OPL_problem
and maybe more, which clash with the would-beOPL_problem
table for the new course.Worse, it seems that as part of cleanup after the fail, that these tables are deleted. Running
OPL-update
brings them back.I discovered this trying to make an "OPL" course for some OPL development.