TableStructureDiscussion

This article has been retained as a historical document. It is not up-to-date and the formatting may be lacking. Use the information herein with caution.

I'm having trouble relating these tables to those that exist in the current SQL incarnation in <nop>WeBWorK2.0. So following is an attempt to fold together the above with what I see as necessary for a gateway test/quiz mode. Of course, it might be that the above isn't supposed to relate to the existing <nop>WeBWorK2.0 tables. Take the following with whatever degree of seriousness it deserves.

I'm assuming the existence of the current set and set_user, problem and problem_user tables, and so have only reproduced the latter of each pair below. A couple of comments regarding the selection of problems for a gateway test follow.

Table: set_user

This gives the definition of an assignment, be it a problem set or a quiz or gateway test, as localized to a given user.

psvn	auto-increment serial number
set_id	id of set this entry is derived from
user_id	id of user this entry is generated for
set_header	set header, if different from that in set
problem_header	problem header, if different from that in set
open_date	open date, if...
due_date	due date, if...
answer_date	answer date, if...
assignment_type	type of assignment: 0 or null for standard homework, other identifying value for gateway/quiz, proctored gateway/quiz, etc. again, values here supercede defaults in set
problem_ordering	whether problems in the set should be arranged in a random order
assignment_length	for tests and quizzes there may be a time limit on each attempt

re: psvn: I think we should get rid of the term "PSVN" altogether and call the serial number an "id" as we will in other tables.
-- Main.SamHathaway - 03 Jan 2004

Table: problem_user

This defines a problem, localized for a user. Each set can have multiple problem s, and similarly for set_user and problem_user.

problem_user_id	this seems to be missing from the current database, which confuses me. but then, I'm easily confused
problem_id	the id of the corresponding problem
set_id	the id of the set to which the problem belongs. hmm. should this be a psvn? should psvn be in here somewhere?
user_id	dum de dum
source_file	the source for the problem. this could be a path to a file, or a generalized URL of some sort. I'm thus thinking of this as including the information in the location entry in the problem table proposed above
value	value of the problem
max_attempts	dum de dum
problem_seed
status
attempted
last_answer
num_correct
num_incorrect
version	version specifier (for versioned problems)
language	language in which the problem is written (i.e. PG, CAPA)

A note about the source_file entry. I'm thinking this could be something like path/filename.pg, or indicate that the source is in a database table, e.g., SQL::source::source_id, indicating that the source has id source_id in the source table. There's one more difficulty with all this, in that for a gateway test we want to change the source with each login. A comment on this follows below.

re: problem_user_id: User problems currently identified by a (user_id, set_id, problem_id) tuple. This should be changed though.
-- Main.SamHathaway - 03 Jan 2004

Table: source

Stores the actual source of a problem.

id	auto-increment serial number
data	problem source

Table: attempt

Stores information about every problem attempt made. It might be that this is only done for gateway tests and quizzes. (I'd like to do it for all problem types -- Main.SamHathaway)

attempt_id	auto-increment serial number
problem_user_id	id of the problem_user with which it's associated
time	time and date of attempt
score	numeric score (between 0 and 1)
data	language-specific attempt data (i.e. serialized <nop>AnswerHash)

Gateway/Quiz notes

In previous discussions I've suggested that we could change the problem seed by resetting it with each login. Looking at the data structure above, it seems that it might be easier to just have the <nop>GatewayQuiz module use the sum problem_seed + num_correct + num_incorrect as the seed for each attempt.

• We've set the seed from the current session key, which is generated randomly.

This was the mechanism we used to implement the random practice user, who got a different version each time they logged in (or timed out).

The point of resetting the problem seed is, of course, to give a different problem with each login. In particular, each problem in the set is in this case really one problem selected from those in a specific topic. This, in part, motivates the choice of the source_file identifier SQL::source::source_id, because I anticipate needing separate listings for each topic. Thus, I can see having successive problems in a gateway access successive source tables, say, source_deriv_sums, source_deriv_prod, source_deriv_chain, etc. In this case we want to pick a random problem from the database, so the source_id value in the source_file entry would be ignored. (small addition 2 Jan) Or it could be set to null or some value like -1 to flag that a random problem from the topic table should be selected.

• I think this can be implemented cleanly from within the .pg language. The content of source_deriv_sums might look like:

        PRE_PROCESS_BLOCK {
            my $sel = random(1,5,1);
            @files = qw( sum_deriv1.pg, sum_deriv2.pg, sum_deriv3.pg );
            my $source_file = $files[$sel];
            PG_INCLUDE($source_file);
         }
       

• There is already a hook in Translator.pm for a preprocessing subroutine which currently scans the entire source file and replaces \ by \\ and BEGIN_TEXT...END_TEXT by TEXT(EV3(<<'END_TEXT');...END_TEXT . This subroutine could be instructed to look for constructions such as the above that are to be executed before the main rendering takes place. -- Main.MichaelGage

See my comment above about divorcing "assignment" from "attempt".
-- Main.SamHathaway - 03 Jan 2004

-- Main.GavinLaRose - 31 Dec 2003