You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm currently working on an import script from ww2 to ww3 and have gotten to the point that I need to flesh out how versioning works in webwork3. So far I have said (and you may have heard me say), "We'll have versions on everything, so we'll make it work". This isn't a good solution as I have figured out.
I've thought of versions on both Problem Sets (homework sets, quizzes, etc.) and on problems. The latter is natural coming from Gateway quizzes, since that is the way we do it in webwork2. In a gateway quiz, a new quiz is a new set of UserProblems--which could just mean new problem seeds, but could also mean a different OPL/local problem. So clearly we will have a version on a UserProblem--this is what was truly lacking in ww2.
Working backwards, my thought is that a UserProblem is linked to a Problem (containing information about the set it is in, the OPL/local problem, weight/value, etc.). Should this also have a version? After thinking this through, I don't believe this should because since a UserProblem is in a one-to-many relationship to a Problem, if a Problem has a version, then a UserProblem would need two versioning variables (one to the Problem version and one to its own version). Because of this, I don't think we should have a version on a Problem.
We can also do an analogous versioning in ProblemSet and UserSet. I'm less clear about the use-case for this. If we have a ProblemSet, called HW #1, for example, we could have a second version of it (either on the course or user level). I could imagine it on the User level in terms of allowing a user to redo a set with a different set of dates for example.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I'm currently working on an import script from ww2 to ww3 and have gotten to the point that I need to flesh out how versioning works in webwork3. So far I have said (and you may have heard me say), "We'll have versions on everything, so we'll make it work". This isn't a good solution as I have figured out.
I've thought of versions on both Problem Sets (homework sets, quizzes, etc.) and on problems. The latter is natural coming from Gateway quizzes, since that is the way we do it in webwork2. In a gateway quiz, a new quiz is a new set of UserProblems--which could just mean new problem seeds, but could also mean a different OPL/local problem. So clearly we will have a version on a
UserProblem
--this is what was truly lacking in ww2.Working backwards, my thought is that a
UserProblem
is linked to aProblem
(containing information about the set it is in, the OPL/local problem, weight/value, etc.). Should this also have a version? After thinking this through, I don't believe this should because since aUserProblem
is in a one-to-many relationship to aProblem
, if aProblem
has a version, then aUserProblem
would need two versioning variables (one to theProblem
version and one to its own version). Because of this, I don't think we should have a version on aProblem
.We can also do an analogous versioning in
ProblemSet
andUserSet
. I'm less clear about the use-case for this. If we have aProblemSet
, called HW #1, for example, we could have a second version of it (either on the course or user level). I could imagine it on the User level in terms of allowing a user to redo a set with a different set of dates for example.Thoughts?
Beta Was this translation helpful? Give feedback.
All reactions