Back to Cumulus Core Support

denis.gerasimov
denis.gerasimov

Full error message from CMS follows:

"SQLSTATE[42000]: Syntax error or access violation: 1170 BLOB/TEXT column 'slug' used in key specification without a key length (SQL: alter table `initbiz_cumuluscore_clusters` add unique `initbiz_cumuluscore_clusters_slug_unique`(`slug`))" on line 664 of D:\Projects\Merki.Online\vendor\laravel\framework\src\Illuminate\Database\Connection.php

MySQL version 5.6.26 for Win64

inIT
inIT

I guess it is because you have MySQL older than 5.7.7. The case is described in Laravel docs, in "Index Lengths & MySQL / MariaDB". In my opinion, the best solution for the problem will be updating MySQL. Give us feedback if this helps, or if you have found any other solution :)

denis.gerasimov
denis.gerasimov

Thank you for really quick reply! I tried both enabling deprecated option innodb_large_prefix on latest MySQL 5.6.x and installing latest MySQL 5.7.x with this option enabled by default. Neither did help, I am still getting the error above.

Actually I don't think that tweaking DB server config can solve this issue since what your update tries to do is NOT supported by MySQL for fields of type TEXT.

IMHO the reason why this error occurs is wrong field type for slug field. In MySQL database it should be VARCHAR(255) rather than TEXT.

This comparison should give you a clear hint how to fix the issue:

YOUR code

$table->text('slug')->unique();

OTHERS' code

$table->string('slug')->nullable()->index(); 
$table->string('slug')->index();
$table->string('slug')->nullable()->index()->unique(); 
inIT
inIT

Yes, we have noticed this mistype a few days ago. This one will be fixed in version 1.1.3 :)

denis.gerasimov
denis.gerasimov

Tried to install v 1.1.5 but still getting the SAME ERROR.

If understand correctly, DB updates are applied sequentially from initial v 1.0.0; thus, fixing this error in newer releases cannot solve my problem. Is there a way to either

a) fix the release package itself, or

b) overcome this some way, or maybe,

c) create an update that detects "clean install" and creates final DB skipping "bad" SQL ALTER queries

Please help :)

Last updated

inIT
inIT

Of course it makes sense. But we cannot just easily change the schema in previous migration files. I have an idea to check in migration methods if engine is problematic version of MySQL and run a different schema builder. This way we can assume, that everyone who has the version had the problem, and all others had not. If you can help with that then pull requests are very welcomed :)

inIT
inIT

Ok dude. After short research I have added two new versions. It should not interfere with existing installations and now it should be possible to install Cumulus Core on your machine. Have fun! :)

1-7 of 7