Re: [WWdevel] relative speed of sql_single and gdbm

[John J. <jj...@as...>]

Arnold Pizer wrote:

> If using case insenstive keys does not mess up how things are read out 
> (e.g. you want set "Exam1" to be in that form, not e.g. "EXAM1" or 
> "exam1"), then it should be easy to enforce that there are no 
> conflicts when userid's, set names, etc are created.
>
> Since I can not imagine that we have any database keys which differ 
> only in case, I'll try this out now.

The only things used as database keys are set_id, user_id, and 
problem_id.  The last one is always a number, so no conflicts are 
possible.  You can double check in a given course by looking at the list 
of sets and list of users in the corresponding instructor pages.

The strings are displayed properly, so that isn't an issue.

Enforcing no conflicts on creation is what would happen by default 
without binary there.  Once you have Exam1, you cannot create exam1 
because the database says exam1 already matches an existing set.  
However, if you created Exam1 and exam1 a week ago (when "binary" was 
there), then webwork would let you do it.  Operating now without binary 
then mucks up the database.

So, simply deleting binary is a reaonsable short term solution.  In 
fact, that is what we are using here at the moment.  Longer term, the 
question is whether to support users/sets which differ only in case.  If 
we want to do that, some other key-scheme should probably be used in the 
database.  This is a moderately big hassle.  If we don't care about 
supporting users/sets which differ only in case, then there is one bug 
to be re-patched (when producing hardcopy for a student, webwork checks 
that the student's user_id matches case sensitively with the user_id of 
the hardcopy being requested - this should be changed to insensitively 
so that students who change capitalization of their user_id on login can 
still get hardcopy).

John