Hi, Tom! On Feb 01, Tom Worster wrote:
Hi Sergei,
base64 makes sense only if I store a base64 encoded value, which is what my ORM extension does (prefixed with 'data:application/octet-stream;base64,') for non-utf8 strings. So I say leave that to me.
Right...
A dynamic column cannot be NULL, so using a JSON null (a different kind of null) to express "dynamic column exists but cannot be represented as requested" should work. The ORM would then have the names and positions in the structure of all the BINARY dynamic columns. With that it can send a SELECT with one or more COLUMN_GET(dyncol_blob, "name" AS BINARY) expressions. I could live with that.
Hmm. May be a dynamic column cannot be NULL now, but this is not a conceptual limitation, there is no logical reason why it coldn't be. So I'd rather keep JSON null for that. What I mean was that the whole COLUMN_GET should fail and return NULL, just as any function does when it gets invalid input: MariaDB [test]> select uncompress("foobar"), 1/0, sqrt(-2); +----------------------+------+----------+ | uncompress("foobar") | 1/0 | sqrt(-2) | +----------------------+------+----------+ | NULL | NULL | NULL | +----------------------+------+----------+ (it can also throw a warning, like uncompress does). Regards, Sergei
What *should* COLUMN_JSON() do when a dynamic column contains BINARY values?
I suppose MariaDB could either return a NULL (meaning "failed", "invalid input", "not possible to convert to JSON") or, may be, base64 this binary data in the output.
But base64 looks like an arbitrary choice, and it, technically, returns something that is *not* the original binary data.