← Back to team overview

maria-discuss team mailing list archive

Re: Restated: JSON cannot represent binary data

 

Hi, Tom!

On Feb 03, Tom Worster wrote:
> Hi Sergei, 
> 
> On 2/3/15, 7:13 AM, "Sergei Golubchik" <serg@xxxxxxxxxxx> wrote:
> 
> >> 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.
> 
> There may be no *technical* reason why it couldn't be but I see no
> *logical* reason why it would be. I can understand how tables (be they
> schema, temp or select) need NULL to say "it's not here" but a dynamic
> column existing and having a "value" of NULL is a non-sequitur. Writing a
> NULL to a dynamic column currently deletes it and I think that makes
> perfect sense. (I think we see know how the word "column" in "dynamic
> columns" can be misleading.)
...

Okay. I think that as our dyncols don't support NULLs and JSON does,
that might be a reasonable solution.

> I see what you mean but it's not a very useful answer. Much more
> useful to get the names, datatypes and structure plus all the values
> that aren't non-unicode strings.

Okay. Would you like to report a bug for that or should I?

Regards,
Sergei



References