Related? 18187

Should be pretty simple to just limit the input for different text types according to the DB limits:
https://www.w3schools.com/tags/att_textarea_maxlength.asp

Related? 18187

Not really since this one broke and the previous one not …

Should be pretty simple to just limit the input for different text types according to the DB limits:

See https://github.com/LimeSurvey/LimeSurvey/blob/e3efd7fb1771e39d18396315fa7b2be56b78e800/application/helpers/expressions/em_manager_helper.php#L9832
Not really … because depend on DB a lot.
And each have own specificity (MSSQL accept 8Mo for whole lines … but text data can take between 8 and 24 BYTES … really complex)

Else : https://gitlab.com/SondagesPro/ExportAndStats/generateGraphQuestion/-/blob/master/generateGraphQuestion.php#L521

@c_schmitz Maybe we can set an arbitrary number considering the minimum size that the different DB engines can handle. What do you think?

Or, as MySQL (and Postgre?) can handle 65k in text fields, we can set that as that as a limit, when using MySQL engine.
If not, we set no limits, as other engines handle really big limits.

What do you think?

Maybe we can set an arbitrary number considering the minimum size that the different DB engines can handle. What do you think?

Please : don't broke plugin … for mysql need to check column type (TEXT (LimeSurvey default) vs MEDIUMTEXT vs LONGTEXT)
Surely for PGSQL too
Unsure for MSSQL

Please : don't broke plugin

What kind of comment is that?

I was thinking on a limit on the html control, not on an update to the DB

@gabrieljenik Set the limit depending on the database type.

What kind of comment is that?

If a plugin or an user update TEXT to LONGTEXT : you need more :) TEXT is the default

I was thinking on a limit on the html control, not on an update to the DB

Not in checkValidityAnswer ? Seems the best place ?
If HTML : no issue for plugin, only for hacked database.

@c_schmitz

Set the limit depending on the database type.

database AND column type : right ?

Or, as MySQL (and Postgre?) can handle 65k in text fields, we can set that as that as a limit, when using MySQL engine.

TEXT : 65k
MEDIUMTEXT : 16,777,215
LONGTEXT : 4,294,967,295

Please find below some analysis done.

Renderer Part:

• Need to make the HTML control not to allow more than XX amount of characters
• Use Maxlength question attribute
• Set default (or validate it is not more than a maximum)
• Review renderers (ex: application/core/QuestionTypes/HugeFreeText/RenderHugeFreeText.php)

Calculating Max Amount:

• How shall we get the "max amount of characters"?

  • Input: question type, DB engine
  • Output: Max Size
  • It is necessary to know the codePage of the DB --> Config File?

• We can split the provess:

  1) Question Type --> Field Type
  2) Field Type + engine --> Max Size

• Question Type --> Field Type

  • Translates from question type to field size
  • New method on QuestionType class ?
  • That logic today is embedded in the prepareTableDefinition of the SurveyActviator
    • Needs code reorganization as to reuse parts of the code
    • Already considers quesiton themes, which can redefine the field type

• Field Type + engine --> Max Size

  • application/helpers/database_helper.php (or similar)

Also, if validation side is also needed:

Validation Part (not required, but may be good idea):

• Need to make the validation not to accept more than XX amount of characters
• Review LimeExpressionManager::checkValidityAnswer()
• Actually the Maxlength is not considered there, so need to implement the rule.

Validation Part (not required, but may be good idea):

? Server side validation is always required … 

PS in checkValidityAnswer : we already have the sgq, then the column name for some question type : we can directly use it DB type.

PS in checkValidityAnswer : we already have the sgq, then the column name for some question type : we can directly use it DB type.

Yes, but you would have to add 1 query for every question... isn't that something to avoid if possible taking into account that is the survey taking process?

If not, create some extra metadata on survey activate.
That metadata can hold each field max sixe.
Then on a single query, get all field sizes.

If not, create some extra metadata on survey activate.

Maybe more in $knownVars variable ?
https://github.com/LimeSurvey/LimeSurvey/blob/86ada39411e982eb43ce2f053fd82f9f95b439e2/application/helpers/expressions/em_manager_helper.php#L119

1. It was in session : https://github.com/LimeSurvey/LimeSurvey/blob/86ada39411e982eb43ce2f053fd82f9f95b439e2/application/helpers/expressions/em_manager_helper.php#L3279
2. can be extended : https://github.com/LimeSurvey/LimeSurvey/blob/86ada39411e982eb43ce2f053fd82f9f95b439e2/application/helpers/expressions/em_manager_helper.php#L4012

or in getQuestionAttributesForEM ? Since it's enter in EMCache

About knownVars : except static var : i think all other can enter in EMCache in future

I see this problem is also present in my 5.4.14 installation, the only difference is that it is triggered by a larger input. I succeeded with a 650K chars input

OK, if setting the limit depending on the database type is too hard, how about we focus on gracefully catching the error., then?

For the Long/huge free text

• MySQL uses the TEXT field type, which can store 64kb bytes (NOT characters, as many UTF-8 chars use more than 1 byte)
• MSSQL uses nvarchar(max) which is 2 Gigabytes
• Postgres uses TEXT which is basically unlimited

Maybe for MYSQL/MARIADB we can use LONGTEXT https://mariadb.com/kb/en/longtext/ for Long text question and/or Huge text question ?
4GB ?

I think 64kb for a long text is a bit too short. while 4GB is way too large.

Suggestion:

• we set it to MEDIUMTEXT in MYSQL (16MB max)
• we limit entry to the same maximum limit of 10MB for all database types
• have a question type attribute that is default set to 1MB, and an option in the question setting to change it (up to 10MB)

What's the benefit of the question attribute? I think we can skip this. Why should be offer a limitation of 10% of what is theoretically possible? I think there is no real use case for this (correct me if I am wrong).

I think 64kb for a long text is a bit too short. while 4GB is way too large.

Why not 4GB for Huge text ?

Short text : TEXT
Long text : MEDIUM
Huge : LONG