Defect #1071

Wiki/News/Documents truncate contents to 64K in MYSQL

Added by W Snyder about 14 years ago. Updated about 10 years ago.

Status:ClosedStart date:2008-04-17
Priority:UrgentDue date:
Assignee:Jean-Philippe Lang% Done:


Target version:0.9.0
Resolution:Fixed Affected version:0.8.7


I've found wiki posts over 64K get silently truncated. The problem is in the SQL specification of the following databases/fields is TEXT (64K) instead of MEDIUMTEXT (16MB) or LONGTEXT (>16MB):

table changesets comments
table comments comments
table documents description
table issues description
table journals notes
table messages content
table news description
table projects description
table wiki_contents text

Perhaps some of these don't need to change but I think most should be MEDIUMTEXT or LARGETEXT (documents for example)?

I have worked around this at my site with using the mysql command:

mysql> ALTER TABLE wiki_contents CHANGE text MEDIUMTEXT ;

but I'm afraid the next db migrate will mess it up, and others will hit it.

I suggest this is urgent priority, since data is lost.

raise_wiki_content_size.patch Magnifier - Rewritten patch from #1404 against r3182 (1.5 KB) Thomas Lecavelier, 2009-12-18 23:52

Related issues

Related to Redmine - Patch #1404: Raise wiki content page size Closed 2008-06-08
Duplicated by Redmine - Feature #3669: Wiki page size too small Closed 2009-07-24
Duplicated by Redmine - Defect #3777: Long wiki pages drop text when edited Closed 2009-08-25

Associated revisions

Revision 3254
Added by Jean-Philippe Lang over 12 years ago

Enlarge wiki content for MySQL databases (#1071).
Limit changed from 64KB to 16MB.


#1 Updated by W Snyder about 14 years ago

There is also a BLOB in wiki_content_versions that should be MEDIUMBLOB or LARGEBLOB.

#2 Updated by Thomas Lecavelier almost 14 years ago

Patch provided for it there: #1404
Hoping it helps.

#3 Updated by Lars Erik Gullerud over 12 years ago

As described in #3777 this bug leads to silent loss of data for project users, is there any estimate on what release(s) the patch in #1404 or a similar solution will be included in?

#4 Updated by W Snyder over 12 years ago

Ping - could the patch or this get integrated? This seems a serious defect. Thanks.

#5 Updated by Jean-Philippe Lang over 12 years ago

  • Category set to Database

#6 Updated by Thomas Lecavelier over 12 years ago

Rewrite from the patch #1404 : set wiki content and versioned content up to 16MB.
I can eventually add a wiki content truncation detection system, but it'd cost a reload of the modified instance. Is this patch ok or should I add the check?

#7 Updated by W Snyder over 12 years ago

IMO 16MB is fine. It becomes a HTML page not an attachment, so 16MB is enough.

#8 Updated by Prof. Dr. YoMan over 12 years ago

Will this go into 0.9?

I needed to split up some documents with big tables into two or more parts which isnt really nice.

#9 Updated by Jean-Philippe Lang over 12 years ago

  • Status changed from New to Resolved
  • Target version set to 0.9.0
  • Affected version (unused) set to 0.8.7
  • Resolution set to Fixed
  • Affected version set to 0.8.7

Fixed in r3254.
A mysql specific migration was added to raise the limit.

#10 Updated by Jean-Philippe Lang over 12 years ago

  • Status changed from Resolved to Closed

Merged in 0.9-stable in r3255.

Also available in: Atom PDF