Moodle

Online Assignment Truncates text at 64k

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: 1.9.2
  • Fix Version/s: 2.0.8
  • Component/s: Assignment
  • Environment:
    Vista, SuSE Linux 10.3 Enterprise
  • Database:
    MySQL
  • Affected Branches:
    MOODLE_19_STABLE
  • Fixed Branches:
    MOODLE_20_STABLE

Description

The Onliine Assignment cuts off text entry at 64k because the data field definition for mdl_assignment_submission data1 and data2 are set to text (64k)

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Kenneth Newquist added a comment -

I can confirm this. The Online Text Assignment fails silently when you have an entry that's longer than 64K, because data1/data2 are set to the type 'text'. Changing it to 'mediumtext' will significantly increase the amount of text that can be stored (from 64K to 16 MB).

This problem also effects Journal (and this is where I first saw the problem crop up) because it's mdl_journal_entries table has a similar limitation on its 'text' field – it's set to type 'text'.

On our campus, the problem occurred while students were using Journal for internship journaling; half the class ran out of space in their journal's halfway through a summer term session (with entries containing 9,000 words, or 55,000 characters). This led me to see if Online Text Assignment had the same limitation, which it did.

Making this change allowed me to add a 21,000 word, 116,000 character document without any problems.

Show
Kenneth Newquist added a comment - I can confirm this. The Online Text Assignment fails silently when you have an entry that's longer than 64K, because data1/data2 are set to the type 'text'. Changing it to 'mediumtext' will significantly increase the amount of text that can be stored (from 64K to 16 MB). This problem also effects Journal (and this is where I first saw the problem crop up) because it's mdl_journal_entries table has a similar limitation on its 'text' field – it's set to type 'text'. On our campus, the problem occurred while students were using Journal for internship journaling; half the class ran out of space in their journal's halfway through a summer term session (with entries containing 9,000 words, or 55,000 characters). This led me to see if Online Text Assignment had the same limitation, which it did. Making this change allowed me to add a 21,000 word, 116,000 character document without any problems.
Hide
Permalink
A. T. Wyatt added a comment -

I would like to see this set as a default value. I should think it would be expecting too much for most people to fix this problem, since they are either unable or reluctant to make database changes.

Show
A. T. Wyatt added a comment - I would like to see this set as a default value. I should think it would be expecting too much for most people to fix this problem, since they are either unable or reluctant to make database changes.
Hide
Permalink
Petr Škoda (skodak) added a comment -

Hello,
database changes are not allowed in STABLE branch, this will have to wait till 2.0

I would not personally recommend encouraging people to to type long essays there because browser may time out or something else might happen which would result in data loss.

Petr

Show
Petr Škoda (skodak) added a comment - Hello, database changes are not allowed in STABLE branch, this will have to wait till 2.0 I would not personally recommend encouraging people to to type long essays there because browser may time out or something else might happen which would result in data loss. Petr
Hide
Permalink
Kenneth Newquist added a comment -

While I agree that timeout's can be a problem, the way things are currently setup folks are already silently losing data because of the database field size limitation – they update their journal entry, save the text, and – unless they're paying attention – don't realize that they've lost text until they go back to edit it. If the field size isn't increased, then IMHO we need some mechanism for warning people that they're hitting the size limit (e.g. like Mediwiki's notice about editing files that are greater than 32kb in length). If it is increased, a similar mechanism could still be added (e.g. "Your entry is longer than the the recommended length of [foo] kb.)

Show
Kenneth Newquist added a comment - While I agree that timeout's can be a problem, the way things are currently setup folks are already silently losing data because of the database field size limitation – they update their journal entry, save the text, and – unless they're paying attention – don't realize that they've lost text until they go back to edit it. If the field size isn't increased, then IMHO we need some mechanism for warning people that they're hitting the size limit (e.g. like Mediwiki's notice about editing files that are greater than 32kb in length). If it is increased, a similar mechanism could still be added (e.g. "Your entry is longer than the the recommended length of [foo] kb.)
Hide
Permalink
Matthew N added a comment -

The truncation can be detected in MySQL by checking for warnings ([1] or "SHOW WARNINGS") or by setting strict mode for the session before the query is run and then checking for the error.

"If strict SQL mode is not enabled and you assign a value to a BLOB or TEXT column that exceeds the column's maximum length, the value is truncated to fit and a warning is generated." – https://dev.mysql.com/doc/refman/5.0/en/blob.html

See also STRICT_TRANS_TABLES/STRICT_ALL_TABLES in https://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html

It would be ideal if this fix could be implemented whenever we are updating a text field with a textarea since this also applies to section summaries and labels (at least in 1.9).

[1] http://www.php.net/manual/en/mysqli.get-warnings.php

Show
Matthew N added a comment - The truncation can be detected in MySQL by checking for warnings ([1] or "SHOW WARNINGS") or by setting strict mode for the session before the query is run and then checking for the error. "If strict SQL mode is not enabled and you assign a value to a BLOB or TEXT column that exceeds the column's maximum length, the value is truncated to fit and a warning is generated." – https://dev.mysql.com/doc/refman/5.0/en/blob.html See also STRICT_TRANS_TABLES/STRICT_ALL_TABLES in https://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html It would be ideal if this fix could be implemented whenever we are updating a text field with a textarea since this also applies to section summaries and labels (at least in 1.9). [1] http://www.php.net/manual/en/mysqli.get-warnings.php

People

Vote (21)
Watch (9)

Dates

  • Created:
    Updated:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Moodle. Try JIRA - bug tracking software for your team.