Gunnar Wolf

Bah, MySQL keeps insisting on being a fun way to waste your time.
One of my clients hosts its systems at Dreamhost, a quite nice hosting company, which has... Well, a couple of strange details :-/
Anyway, people who work with databases know that a BLOB (or its equivalent) is the right datatype for storing images or, in general, files, right? After all, BLOB is just an acronym for Binary Large OBject. And if somebody has a BLOB field in the DB and searches on it, most RDBMS-bound programmers will at very least chuckle at a design flaw - BLOBs are just to be stored and retrieved, that's it.
Well, the system I wrote for this client uses a BLOB field - Ok, to be clear: I just declared it as a :binary in the corresponding migration. That should do the trick, and should allow me to keep my system RDBMS-independent, right? So I can still work on my development system using nice-and-trusty PostgreSQL
Anyway... My client said some documents were being corrupted. And that is Not Nice^TM... Documents were being truncated at 63Kb. The bug was consistent across the three instances of my system in Dreamhost, but could not be reproduced at my machines - It didn't take too long to find out it must be the DB (and that's partly because I don't really trust MySQL :) ).
Turns out that, in MySQL speak, there are four types of blobs: TINYBLOB, BLOB, MEDIUMBLOB, and LONGBLOB. Forgoodnessake, WHY?! The stupidiest one is the tinyblob: A Binary Large OBject limited to 8 bits (255 characters). Regular blobs are 16 bit long (65535 characters - Aha! That's your 63.99Kb limit!). Mediumblobs are 24 bits (16 million), and longblobs are 32 bits (4000 million). And, of course, the blob datatype is not large at all.
Bah.
Anyway... At least this is an open and known issue already to the Rails people, and I do expect them to change the migration equivalencies to something saner.
Bah again.