The constant_name column is a varchar(255) but when using UTF-8, characters are multibyte, so in reality the maximum size is far less than 255. As an example
Pecularities in many browsers may mean that the output below enters your screen in sudden jerks and that there are long pauses of several seconds where it appears as though things may have crashed. That is not the case, you will eventually see output coming out line by line. There may be sequential numbers appearing below, this is to indicate that even though nothing else may be displaying there is activity going on. These numbers will be interspersed with the content of the billing and that is normal.
is truncated to:
Pecularities in many browsers may mean that the output below enters your screen in sudden jerks and that there are long pauses of several seconds where it appears as though things may have crashed. That is not the case, you will eventually see output co
The constant_name is a needed key to keep the queries quick and is also in BINARY to allow constants with different casing. Is there a way to make this longer but still keep it a key and support different casing?
Here’s a thought. You could replace the cons_id key with a hash (e.g. md5 or sha1) of the constant name. That way, given the constant, you can compute the hash and look up the definition from that. The queries would be simpler (only one table), keys shorter, and the lang_constants table would be needed only as a reference of what constants are supported.
That would require code changes and need to support both mechanisms.
What about making it a blob and putting a key with length of 50 on it. That should remove the limit constraint, maintain casing differences, and keep performance with the key.
