Re: [OpenWeBWorK-devel] WWDBv3

[Sam H. <sa...@uo...>]

On Nov 18, 2004, at 9:25 AM, Michael Gage wrote:

> On Nov 12, 2004, at 5:11 PM, Sam Hathaway wrote:
>
>> Hi all,
>>
>> Here's the first draft of the schema for WWDBv3, the long-promised  
>> SQL-only database schema for WeBWorK:  
>> <http://devel.webwork.rochester.edu/twiki/bin/view/Webwork/ 
>> DatabaseSchemaV3>. Some features:
>
> Hi Sam,
>
> I've finally had a chance to look at this a bit, not thoroughly yet,  
> but what I've seen so far looks good.
>
>   I would like to see a space for
> options/preferences, probably in the "participants" space, although  
> possibly in the "user" space for default preferences.
>
> What I want is a place to store
> the current options for "displayMode", and for "showOldAnswers",  
> although I expect that once we have
> this capability there will be requests to allow other aspects of the  
> user interface to be customized as well.

I've added display_mode, show_old_answers, show_correct_answers,  
show_hints, and show_solutions columns to the users table, with the  
caveat that we might not want to allow normal students to set the  
latter three.

I wonder if, in addition to this per-user default (set in User  
Options), we should make it so that if a user explicitly sets one of  
these options in a problem's View Options panel we save those options  
for that problem only, with an option to "reset to defaults".

> This would be mean that as a rule the only state that needs to be  
> passed from one webpage to another in hidden
> variables would be "user", "key", "course", "set", "problem",  and  
> possibly a few other specialized hidden variables
> used when a page calls itself and wants to indicate success or failure.

The only hidden variable that we'll need on a regular basis is "key",  
since "course", "set", and "problem" are encoded in the URL and "user"  
can be stored in the session (which could map key -> [ user, timestamp,  
etc. ]).

It's somewhat dangerous to store certain data in the session object, as  
it could prevent the user from performing multiple concurrent  
operations in the same session. For example, if we wrote the editor to  
store unsaved source for preview in the session, then this could  
happen:

The professor starts editing a problem, and then previews it in a new  
window (preview A). She then continues to edit and previews it in  
another new window (preview B). If she then goes back to preview A and  
attempts it, her submissions will be compared to the version of the  
problem in preview B, and that version will be displayed when the page  
loads.

(Of course, it's OK to store preference data in this way because  
there's no need for concurrency there. But the UI has to make it clear  
that it's a preference.)

We can store things that would cause problems as above in the session  
as long as they're uniquely identified in some way. If the editor  
assigned a unique ID to each version of the source previewed, and then  
that information was passed to the editor in the request, we wouldn't  
have the problem above. On the other hand, then you're carrying around  
another (shorter) param in the request.

(The logical extension of this is just keeping the process's stack in  
the session, i.e. continuations.)
-sam