Long snmp_indexes are being cut off

[rprofijt]

Seems like this was reported before in #864

After migration form 0.8x to 1.1.38 we had some long OID's that were being cut off in the snmp_index field, we have altered them in the host_snmp_cache now:

-  snmp_index varchar(191) NOT NULL default '',
+  snmp_index varchar(255) NOT NULL default '',

-  KEY snmp_index (snmp_index),
+  KEY snmp_index (snmp_index(191)),

I this is something likely to happen to other people. Probably caused by the fixes for the uft8mb4 compatibility.

[netniV]

It's actually down to a limitation on the amount of data that can be held in an index. The strange part is that you are allowing a larger value than you are indexing which can cause issues in itself from my knowledge.

[rprofijt]

I don't know what you mean? In al the other tables the field is a varchar(255), but not in the host_snmp_cache. So that seems inconsistent.

[netniV]

Let us review this and come back to you as I hadn't looked at the other tables.

[cigamit]

Yea, this one needs to be addressed. I know a few users who have this column at 1024 bytes. We need to fix prior to release.

[cigamit]

@rprofijt, can you please follow this procedure and let me know if it resolves your issue:

https://laracasts.com/discuss/channels/tips/mariadb-utf8mb4-and-string-indexes-hitting-the-error-specified-key-was-too-long-max-key-length-is-767-bytes

[netniV]

Didn't we have an issue open for adding dynamic as part of the table conversion? Should the installer be looking for those that aren't?

[rprofijt]

@cigamit The only issue we had is that the size of the field was not 255, we are still using latin1.

[cigamit]

Then, you should be safe. Since we are trying to be i18n compliant, these two settings are pretty important if you are in asia.

[cigamit]

Moving this to 1.3 for now.