[4889] SMF 2.x and MySQL Cluster Limitation

[ehsanf]

I tried installing SMF 2.0 (RC5) on MySQL Cluster (5.1 NDB 7.1) and noticed an incompatibility.

mysql> CREATE TABLE smf_openid_assoc (
    ->   server_url text NOT NULL,
    ->   handle varchar(255) NOT NULL default '',
    ->   secret text NOT NULL,
    ->   issued int(10) NOT NULL default '0',
    ->   expires int(10) NOT NULL default '0',
    ->   assoc_type varchar(64) NOT NULL,
    ->   PRIMARY KEY (server_url(125), handle(125)),
    ->   KEY expires (expires)
    -> ) ENGINE=NDBCLUSTER;
ERROR 1073 (42000): BLOB column 'server_url' can't be used in key specification with the used table type

I think changing it to the following will fix, but I am not sure if it has any side effects:
...
    ->   server_url varchar(255) NOT NULL,
...
    ->   PRIMARY KEY (server_url, handle),

Another example is:
mysql> CREATE TABLE `smf_settings` (
    ->   `variable` varchar(255) NOT NULL default '',
    ->   `value` text NOT NULL,
    ->   PRIMARY KEY  (`variable`(30))
    -> ) ENGINE=NDBCLUSTER;
ERROR 1089 (HY000): Incorrect prefix key; the used key part isn't a string, the used length is longer than the key part, or the storage engine doesn't support unique prefix keys

[Joshua Dickerson]

We either need to say that we don't support NDB (which is true because I've yet to hear of someone testing on it) or fix these. I am inclined to say that it isn't supported right now.

The first issue is easy - varchar(255) (or whatever the maximum length we'd expect a URL to be). The second one isn't so easy since it is telling us that there are 3 possible errors there.

[Arantor]

The issue with the second case is that NDB Cluster can't do prefix indexes. While we could theoretically do non prefix indexes, for the quite-a-few places we do it it is not particularly viable to either reduce the column size (and then make the index up to the size of that entry) or increase the key size.

Going to have to say at this point that NDB Cluster isn't an engine we can meaningfully support without a database redesign which won't happen with 2.x.