MySQL Bugs: #25225: Maximum attribute length has changed?

Bug #25225	Maximum attribute length has changed?
Submitted:	20 Dec 2006 20:40	Modified:	19 May 2009 13:48
Reporter:	Geoff Crossland	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Cluster: Cluster (NDB) storage engine	Severity:	S3 (Non-critical)
Version:	mysql-5.1	OS:	Linux (Linux 2.6.9)
Assigned to:		CPU Architecture:	Any
Tags:	5.1.14-beta (built with GCC 3.4.3), cluster, documentation

Description:
In 'Known Limitations of MySQL Cluster' (http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-limitations.html), it is stated that 'attribute names are truncated to 31 characters, and if not unique after truncation give rise to errors.' However, errors are not reported at either table creation or tuple insertion time and (for some simple test cases) attribute names of greater than 31 characters (up to and including 63) can be used successfully.

How to repeat:
Successful use of a table with two attributes which differ only at the 32nd character:

CREATE TABLE TestTable0 (XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXA INTEGER(10), XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXB INTEGER(10)) engine=ndbcluster PARTITION BY KEY(XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXA);
INSERT INTO TestTable0(XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXA, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXB) VALUES (13, 29);
SELECT * FROM TestTable0;

Similarly for attributes only differing at the 63rd character:

CREATE TABLE TestTable1 (XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXA INTEGER(10), XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXB INTEGER(10)) engine=ndbcluster PARTITION BY KEY(XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXA);
INSERT INTO TestTable1(XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXA, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXB) VALUES (13, 29);
SELECT * FROM TestTable1;

The new limit seems to be before 63 characters, since tables cannot be created with attributes not unique until the 64th character:

CREATE TABLE TestTable2 (XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXA INTEGER(10), XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXB INTEGER(10)) engine=ndbcluster PARTITION BY KEY(XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXA);
INSERT INTO TestTable2(XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXA, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXB) VALUES (13, 29);

Suggested fix:
If the NDB table attribute identifier limits have been changed, update 'Known Limitations of MySQL Cluster.' Otherwise, correctly emit errors when attempting CREATE TABLE statements with too-long attribute names.

See also bug# 44940

Corrected category/status/lead/severity. (Wrong information != feature request)

Set Jeb as Verifier since he's the one who assigned it to me.

I can't fine anything in the docs, changelogs, worklogs, etc. to suggest that there was a decision to change this behaviour. Rather, we've neglected to enforce the documented limit.

The documentation currently states that you can rely only on the first 32 characters of a table name. IOW, we don't guarantee the uniqueness of anything greater than 32 characters, and users should not rely on this "appearing to work" with longer table names than that. The fact that we allow longer table names when they're of no use and lead to problems such as that found in BUG#44940 is a misfeature, and this is what needs to be corrected.

Therefore, I'm setting the category of this bug back to Server and asking that creating NDB tables with names longer than 32 characters be disallowed. This will also solve the issue in BUG#44940.

Removed myself and Stefan from this bug, since it's not a Docs issue until it's fixed.