I am setting up a SNG7 install, and things were going great, I love the new FreePBX. But, I decided to run though module admin updates as I saw updates available, the system isn’t in production, and I know that FreePBX 14 is still early in dev phase.
I now have a basically unusable system, I got the following errors:
@tm1000 This is just a guess, but since you “pulled” 190 out of the air, and it worked, perhaps there is a typo in the userman code and it should be 190. Because 190 works as is, its the 255 that doesn’t work
I should have clarified that it does not and will not fix the issue. I had to know the key length that I proposed was supported and did not want to spin up a vm to test. Thank you for doing that.
There’s nothing to consider but thanks. The databases in the 7 distro support UTF8 in a wider scope than in 13 (and 12 didnt support UTF8 at all). Supporting UTF8 puts restrictions on column lengths because 1 characters is not 1 byte in UTF8. It can be 1,2 or 4 bytes. Depending. In FreePBX 12 it was 1 byte, in 13 it was 2 bytes and in 14 it’s 4 bytes. Thus a normal column length may have a max of 255 bytes, in previous versions of freepbx 255 characters equalled 255 bytes. However now it’s something closer to 255 characters is equal to 1,020 bytes (255 * 4 = 1020). The error says it needs to be 767. So 190 * 4 = 760 and it’ll work. So will 191. But I like even numbers.
Anyways module authors that have defined indexes in mysql will have to shorten their column length on certain columns
It’s not a typo and I didn’t pull it out of the air. 190 * 4 = 760 which is less than 767. It just needed a full explanation.
@tm1000 I understand, yes it was no trouble for me to give the code a try. As I mentioned above, I have already faced a similar issue, so I did research into column byte length restrictions relating to UTF8. It does seem that MariaDB 10.1.02 has fixed this issue, but thats fairly advanced MariaDB compared to 5.5. I tried installing MariaDB 10, but then I couldn’t get asterisk and freepbx to connect.
Thank you for the clear explanation though. It helps both me and others who might read this.
What would you say my best plan is at this point to get my system back to operable? Can I downgrade the module? Should I just wait for a fix to be implemented/Should I open a jira ticket?
This isn’t a random module, i expect almost any FreePBX 14/ SNG7 system would be broken my upgrading Userman at this point, so i’m guessing your just going to tell me to chill out and it will be fixed soon enough.