Project

General

Profile

Actions
Copy link

Defect #1071

closed

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

Added by W Snyder about 15 years ago. Updated about 11 years ago.

Status:
Closed
Priority:
Urgent
Assignee:
Jean-Philippe Lang
Category:
Database
Target version:
0.9.0
Start date:
2008-04-17
Due date:
% Done:

0%

Estimated time:
Resolution:
Fixed
Affected version:
0.8.7

Description

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.

Files

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

Related issues

Related to Redmine - Patch #1404: Raise wiki content page sizeClosedJean-Philippe Lang2008-06-08

Actions
Has duplicate Redmine - Feature #3669: Wiki page size too smallClosed2009-07-24

Actions
Has duplicate Redmine - Defect #3777: Long wiki pages drop text when editedClosed2009-08-25

Actions
Actions
Copy link
 #1

Updated by W Snyder about 15 years ago

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

Actions
Copy link
 #2

Updated by Thomas Lecavelier almost 15 years ago

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

Actions
Copy link
 #3

Updated by Lars Erik Gullerud almost 14 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?

Actions
Copy link
 #4

Updated by W Snyder over 13 years ago

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

Actions
Copy link
 #5

Updated by Jean-Philippe Lang over 13 years ago

  • Category set to Database
Actions
Copy link
 #6

Updated by Thomas Lecavelier over 13 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?

Actions
Copy link
 #7

Updated by W Snyder over 13 years ago

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

Actions
Copy link
 #8

Updated by Prof. Dr. YoMan over 13 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.

Actions
Copy link
 #9

Updated by Jean-Philippe Lang over 13 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.

Actions
Copy link
 #10

Updated by Jean-Philippe Lang over 13 years ago

  • Status changed from Resolved to Closed

Merged in 0.9-stable in r3255.

Actions
Copy link

Also available in: Atom PDF