Hi, Tom! On Feb 03, Tom Worster wrote: > Hi Sergei, > > On 2/3/15, 7:13 AM, "Sergei Golubchik" <s...@mariadb.org> 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 _______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
