Data generation throws data truncation error about snofyre HOT 9 CLOSED

Example: generating all patients who have 234347009|Anemia of chronic disease|

The long normal form for this concept (before any further random 
subspecialisation by adding e.g. optional qualifiers) is 212 characters long:

234347009|Anemia of chronic disease|
Equals 
38292009:47429007=(64572001:263502005=90734009),363705008=(62574001:{363713009=2
81300000,363714003=(14089001:246093002=41898006,116686009=(123038009:{118169006=
41898006,370133003=33463005}),260686004=129266000)})

[deleted comment]

This is a known issue because the field storing the Normal Form was set to 
VARCHAR(256) to start with. This is the max length of VARCHAR datatype 
supported in MySQL upto version 5.0.3. It can be increased now, because it has 
been addressed in versions 5.0.3 and over. See below from MySQL documentation: 
http://dev.mysql.com/doc/refman/5.0/en/string-type-overview.html

 [NATIONAL] VARCHAR(M) [CHARACTER SET charset_name] [COLLATE collation_name]

A variable-length string. M represents the maximum column length in characters. 
In MySQL 5.0, the range of M is 0 to 255 before MySQL 5.0.3, and 0 to 65,535 in 
MySQL 5.0.3 and later. The effective maximum length of a VARCHAR in MySQL 5.0.3 
and later is subject to the maximum row size (65,535 bytes, which is shared 
among all columns) and the character set used. For example, utf8 characters can 
require up to three bytes per character, so a VARCHAR column that uses the utf8 
character set can be declared to be a maximum of 21,844 characters.

[deleted comment]

[deleted comment]

[deleted comment]

I've now increased the column length for any expression or derivative store in 
compositional grammar form to the max value of 65535. This might be overkill 
for most cases, but at at we shouldn't have any hidden data truncation error 
surprises!

To install the patch:
1. Drop the attached jars into your Snofyre/bin/lib folder (select yes when 
warned about overwrite)
2. You now have two options
  # If you are happy to lose your existing data, then change open the Snofyre/bin/settings/fake-data.properties file and change line 16 from hibernate.hbm2ddl.auto=validate to hibernate.hbm2ddl.auto=create   Now when you start Snofyre, it'll recreate the new schema for you (give it a few mins..for all UI to load). Remember to revert line 16 to hibernate.hbm2ddl.auto=validate after the new schema has been created. 
  # If you want to retain your existing data, then from MySQL Query Browser you can edit the schemas for the following tables to unique_expressions_table, clinical_expressions, CLINICAL_ENTRY and CLINICAL_ENTITY to replace all VARCHAR(255) with VARCHAR(65535)

Let me know how it goes... :)

Doesn't work: I dropped the original fakedata2 and then re-created it again as 
an empty. After starting SnoFyre with the 'create' option, it populated the 
schema with a load of tables EXCEPT the four mentoned above. I then loaded the  
MI sample query and tried to generate against it, and got the same error 
'nesting problem' message as previously. See attached log.

Previous fix does not work because the it exceeds the max limit on row size... 
now all appropriate datatypes mapped to VARCHAR(2560)...

Same instructions as before, but if u drop the fakedata2 schema, please 
recreate it yourself