← Back to team overview

maria-discuss team mailing list archive

Re: The future of Dynamic Columns

 

Hi Sergei,

Your reply complements Oleksandr's and is welcome.

Your remarks about tepid user response to Dynamic Columns makes me want to
reiterate the comments about better marketing my reply to Oleksandr. But
you make even more clear that the flip side is very important. Users need
to show their love. I'll forge ahead with the ORM extension and perhaps we
can generate some users in the Yii community. Maybe then we can write up
something for mariadb.com. Maybe we can even make Rails and Doctrine users
covet:-) 

Some more responses inline below..


On 1/28/15, 10:16 AM, "Sergei Golubchik" <serg@xxxxxxxxxxx> wrote:

>That could as well be. And it's bad. What is worse - they're turned away
>without complaining so we don't know what to do to fix dynamic columns.
>
>Any suggestions how we can make the syntax less clunky?

I had to invent a "dynamic attribute token" notation for the ORM to make
it work in general. It might be of interest:
https://github.com/tom--/dynamic-ar#dynamicactivequery

For the SQL, what PostgreSQL did looks reasonable, although I haven't used
it in anger yet. Here's a brief intro:
http://clarkdave.net/2013/06/what-can-you-do-with-postgresql-and-json/


>>   5. The requirement to specify datatype when querying a dynamic column
>>is
>> agonizing. The manual says it is a limitation of SQL itself (presumably
>> immutable) but PostgreSQL manages to avoid it when querying jsonb doc
>> properties.
>
>We could workaround this requirement by assuming everything is a string,
>for example. This can be implemented, if that's what users want.

This is better than nothing but perhaps doesn't add much. In the context
of a webapp CHAR will very often be the correct choice. In my design, I
use CHAR as default unless specified otherwise, as described in the README
I linked above.

Another possibility is to provide a function that returns a string that is
an SQL representation of the dynamic column's value and its datatype. It
would always involve a cast. If you were to use this string verbatim in an
insert, you'd get exactly the same thing. The DB abstraction layer has the
option map datatypes.


>>   7. I head a rumor that some kind of JSON features are coming to Maria.
>
>I wonder what exactly you've heard and where :)

On Jan 24th, I was told "json support is in the road map" in #maria on
Freenode. Nothing more.


>But now is the time to affect the 10.2 roadmap. What "JSON features"
>would you like to see in MariaDB?

None! Not if I'm going to be working on this :P

Tom




Follow ups

References