| Bug #6546 | NDB does not interpret a single KEY definition as PRIMARY KEY | ||
|---|---|---|---|
| Submitted: | 10 Nov 2004 12:43 | Modified: | 17 Dec 2004 22:28 |
| Reporter: | Martin Skold | Email Updates: | |
| Status: | Won't fix | Impact on me: | |
| Category: | MySQL Cluster: Cluster (NDB) storage engine | Severity: | S3 (Non-critical) |
| Version: | 4.1.7 | OS: | Any |
| Assigned to: | Assigned Account | CPU Architecture: | Any |
[10 Nov 2004 12:57]
Martin Skold
Changed version and removed showstopper flag
[17 Dec 2004 22:28]
Tomas Ulin
this is really a limitation with current hidden key implementation that uses autoincrement and thus the table cannot use another autoincremented column, should be documented under "limitations"
[13 Mar 2014 13:33]
Omer Barnir
This bug is not scheduled to be fixed at this time.

Description: At CREATE TABLE the ndbcluster handler requires that a primary key is defined as PRIMARY KEY. I single KEY definition is also by definition a primary key (if NOT NULL) and can be used as PRIMARY KEY. How to repeat: CREATE TABLE affiliates_logs ( id_affiliates_logs mediumint(8) unsigned NOT NULL auto_increment, id_affiliates mediumint(5) unsigned NOT NULL, host varchar(32) NOT NULL , ip varchar(24) NOT NULL, date datetime NOT NULL, aff_liste tinyint(3) unsigned NOT NULL , aff_fiche tinyint(3) unsigned NOT NULL , aff_form tinyint(3) unsigned NOT NULL , aff_confirm tinyint(3) unsigned NOT NULL , KEY id_affiliates_logs (id_affiliates_logs) ) ; ERROR 1005 (HY000): Can't create table './test/affiliates_logs.frm' (errno: 4335) adding the PRIMARY keyword: CREATE TABLE affiliates_logs ( id_affiliates_logs mediumint(8) unsigned NOT NULL auto_increment, id_affiliates mediumint(5) unsigned NOT NULL, host varchar(32) NOT NULL , ip varchar(24) NOT NULL, date datetime NOT NULL, aff_liste tinyint(3) unsigned NOT NULL , aff_fiche tinyint(3) unsigned NOT NULL , aff_form tinyint(3) unsigned NOT NULL , aff_confirm tinyint(3) unsigned NOT NULL , PRIMARY KEY id_affiliates_logs (id_affiliates_logs) ) ; Query OK, 0 rows affected (0.93 sec)