maria-discuss team mailing list archive

[Tom Worster <fsb@xxxxxxxxxx>]

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.

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.


Tom


On 2/1/15, 3:45 PM, "Sergei Golubchik" <serg@xxxxxxxxxxx> wrote:

>Hi, Tom!
>
>On Jan 31, Tom Worster wrote:
>> I think we're getting lost in the detail. Beyond dispute are two facts:
>> 
>>    1. BINARY is a valid datatype in dynamic columns.
>>    2. JSON cannot represent binary data.
>> 
>> It follows that:
>> 
>>    COLUMN_JSON() cannot (correctly) represent all dynamic column values.
>> 
>> So I ask the question is:
>> 
>>     What *should* COLUMN_JSON() do when a dynamic column contains BINARY
>> values?
>> 
>> When I file a bug report, I like to give an expected result. I don't
>>know
>> what it is in this case. Every other decent JSON encoder errors on such
>> input. Is that what Maria should do?
>
>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.
>
>Regards,
>Sergei
>