Moodle
  1. Moodle
  2. MDL-39342

Non-descript database error when question answer is too long

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.3.3
    • Fix Version/s: 2.3.7, 2.4.4
    • Component/s: Questions
    • Labels:
    • Testing Instructions:
      Hide

      1. Try to create a matching question whith an answer that is longer than 255 characters. You should not be able to type more than 255 characters into the answer box.

      2. Check that a question with exactly 255 unicode chars in the answer will save. (Hint: 一二三四五六七八九十 is 1 - 10 in Japanese. Copy that 25 and a half times.)

      Show
      1. Try to create a matching question whith an answer that is longer than 255 characters. You should not be able to type more than 255 characters into the answer box. 2. Check that a question with exactly 255 unicode chars in the answer will save. (Hint: 一二三四五六七八九十 is 1 - 10 in Japanese. Copy that 25 and a half times.)
    • Affected Branches:
      MOODLE_23_STABLE
    • Fixed Branches:
      MOODLE_23_STABLE, MOODLE_24_STABLE
    • Pull from Repository:
    • Pull 2.4 Branch:
    • Pull Master Branch:
    • Rank:
      49971

      Description

      When creating a matching question, supplying an answer over 255 characters results in the non-descriptive error message, "Error writing to database. More information about this error."

      It would be much better if the response had one or more of these responses: name the field ("Answer 1"), more detailed error ("input is too long for field (255 character limit)"), return the browser to the input form with that field highlighted, etc.

      Ideally, this would be implemented as part of Moodle's libraries (not specific to the question import routine), so it would benefit all forms.

      A complimentary approach would be to validate the input before submitting or during data entry.

      I searched for similar trackers and found some about fields too long, but none for questions in particular, and none that seemed general enough (just from the title, at least) to cover the issue globally. This is the first tracker I've filed, so please let me know if I've missed anything.

      We are running 2.3.2+ with MySQL on Ubuntu.

        Activity

        Hide
        Tim Hunt added a comment -

        Well, the answer to a matching question gets displayed in a dropdown menu. I can't think of any circumstances where a 256-character answer (or longer) would be helpful.

        So, what we should be doing is catching this during form validation.

        Show
        Tim Hunt added a comment - Well, the answer to a matching question gets displayed in a dropdown menu. I can't think of any circumstances where a 256-character answer (or longer) would be helpful. So, what we should be doing is catching this during form validation.
        Hide
        Dan Poltawski added a comment -

        Hmm well, the solution you've created just puts a hard limit on the html form, is that better than complaining about the length afterwards? like:

        mod/forum/post_form.php:        $mform->addRule('subject', get_string('maximumchars', '', 255), 'maxlength', 255, 'client');
        
        Show
        Dan Poltawski added a comment - Hmm well, the solution you've created just puts a hard limit on the html form, is that better than complaining about the length afterwards? like: mod/forum/post_form.php: $mform->addRule('subject', get_string('maximumchars', '', 255), 'maxlength', 255, 'client');
        Hide
        David Hempy added a comment -

        Tim - Agreed, an answer that long would not be terribly useful. This came up when a user was creating a question an accidentally pasted the wrong (and very long) thing into the answer box. So while we can chalk it up as operator error, it took us a while to figure out where the problem was even coming from, and due to our workflow she was making the same mistake when trying it over.

        So, while this is not a terribly critical fix for matching questions, it would be useful if the more general database libraries in Moodle (I'm assuming there's a database abstraction layer...I have never tinkered with any Moodle code), relate the database error more fully. Even reporting "Data Truncation Error" might not be the friendliest message, but would clue in most users to go back and look for long entries.

        Dan - Yes, I think validating/restricting input upfront nips a lot of problems in the bud.

        Thanks to both of you for your work on this! I did not expect such a quick response, and I'm quite impressed!

        If I'm supposed to do something more on this ticket, please tell me – I'm new at this.

        Show
        David Hempy added a comment - Tim - Agreed, an answer that long would not be terribly useful. This came up when a user was creating a question an accidentally pasted the wrong (and very long) thing into the answer box. So while we can chalk it up as operator error, it took us a while to figure out where the problem was even coming from, and due to our workflow she was making the same mistake when trying it over. So, while this is not a terribly critical fix for matching questions, it would be useful if the more general database libraries in Moodle (I'm assuming there's a database abstraction layer...I have never tinkered with any Moodle code), relate the database error more fully. Even reporting "Data Truncation Error" might not be the friendliest message, but would clue in most users to go back and look for long entries. Dan - Yes, I think validating/restricting input upfront nips a lot of problems in the bud. Thanks to both of you for your work on this! I did not expect such a quick response, and I'm quite impressed! If I'm supposed to do something more on this ticket, please tell me – I'm new at this.
        Hide
        Tim Hunt added a comment -

        Dan, in general I would agree with you. In this specific case, 255 chars is so crazily long compared to what a sane user would type into this box that I think we should go with my simpler fix.

        Show
        Tim Hunt added a comment - Dan, in general I would agree with you. In this specific case, 255 chars is so crazily long compared to what a sane user would type into this box that I think we should go with my simpler fix.
        Hide
        Dan Poltawski added a comment -

        The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

        TIA and ciao

        Show
        Dan Poltawski added a comment - The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week. TIA and ciao
        Hide
        Dan Poltawski added a comment - - edited

        Of course, a user might actually paste it and not notice their question is truncated

        (I'm fine either way)

        Show
        Dan Poltawski added a comment - - edited Of course, a user might actually paste it and not notice their question is truncated (I'm fine either way)
        Hide
        Damyon Wiese added a comment -

        Thanks Tim,

        Both options are client side so it seems there's not much difference.

        Integrated to 23, 24 and master.

        Show
        Damyon Wiese added a comment - Thanks Tim, Both options are client side so it seems there's not much difference. Integrated to 23, 24 and master.
        Hide
        Damyon Wiese added a comment -

        Test passed on 23, 24, and master.

        Thanks Tim.

        Show
        Damyon Wiese added a comment - Test passed on 23, 24, and master. Thanks Tim.
        Hide
        Dan Poltawski added a comment -

        Thanks! You're changes are now spread to the world through this git and our source control repositories.

        No time to rest though, we've got days to make 2.5 the best yet!

        ciao

        Show
        Dan Poltawski added a comment - Thanks! You're changes are now spread to the world through this git and our source control repositories. No time to rest though, we've got days to make 2.5 the best yet! ciao

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: