"1071 Specified key was too long" will never be resolved with Schema::defaultStringLength(191) about geonames HOT 3 CLOSED

Thanks @thbighead for posting the issue!

Suggested Improvement to Laravel

Yeah, this could be solved by Laravel allowing us to specify a prefix length for the string indexes.
Reading through the issues posted on the Laravel repository...
Link to GitHub issue: Ability to define index key length while creating schema

It seems like that is being discussed, but no idea when they will get it implemented.

Solution

So for our purposes, I have added some logic around the creation of the two troubled indexes in the migrations.
For example: Link to relevant code: Alternate Names Table Migration

The index will only be created, if the database driver is 'mysql' and it doesn't have an environment variable set indicating that its being run as part of a continuous integration service.

I am using travis-ci.org and it was throwing an error about the syntax I was using. Since these indexes aren't needed as part of the unit tests, I am not creating them under those circumstances.

Regarding indexes you might not need

It was suggested that I could just not create the indexes at all. Some people just won't need them. A fair point. But I need them. ;)
So it would be just as easy to suggest that each user can decide for themselves what indexes they want to delete and which they want to keep. (...as long as creating them doesn't throw an exception :) )

from geonames.

Same issue, solved migration by commenting :

from geonames.

Open file config/database.php and change the strict mode to false under 'mysql'.

https://i.imgur.com/ezinPdn.png

from geonames.