That's right, JSON operators are not implemented, MariaDB has never claimed otherwise. I can convert it into a feature request, since I can't find an existing one.

> a feature request
У меня на этот счёт иное мнение.
MariaDB себя всегда позиционировала как прозрачная замена MySQL, то есть пользователи в любое время имеют возможность мигрировать с MySQL на MariaDB.
Следовательно, первоочередная задача MariaDB поддерживать всё, что поддерживает MySQL.
И при этом, в выпуске 10.2 была заявлена поддержка данных типа JSON. Не частичная поддержка, а поддержка, следовательно, она должна быть полной, тем более явных упоминаний о несовместимости с MySQL и о нереализованных функциях, а также инструкции по миграции с MySQL с упоминанием о нереализованном функционале не было.

Поправьте меня, пожалуйста, если я в чём-то ошибаюсь.

В принципе мне не важно чем это будет считаться тут багом или запросом на фичу, лишь бы к этому отнеслись серьёзно и реализовали как можно скорее.

P.S. Извините, что на русском, но я смотрю тут преимущественно везде русские имена и фамилии, а с английским у меня плоховато и мне очень трудно переводить на английский язык сложно составленные предложения.

MariaDB себя всегда позиционировала как прозрачная замена MySQL, то есть пользователи в любое время имеют возможность мигрировать с MySQL на MariaDB.

MariaDB isn't positioning itself as a drop-in replacement for MySQL anymore, ever since 10.x release line.

Следовательно, первоочередная задача MariaDB поддерживать всё, что поддерживает MySQL.

While MariaDB still makes some effort to support MySQL functionality which is deemed valuable, supporting everything is definitely not the most important goal.

И при этом, в выпуске 10.2 была заявлена поддержка данных типа JSON. Не частичная поддержка, а поддержка, следовательно, она должна быть полной, тем более явных упоминаний о несовместимости с MySQL и о нереализованных функциях, а также инструкции по миграции с MySQL с упоминанием о нереализованном функционале не было.

That's not quite true. 10.2 only declares (and implements) support of JSON functions. In latest versions an alias for JSON type was added for easier migration of MySQL data dumps, but that's still not the same JSON data type as in MySQL and is not declared as such.
What for the absence of an explicit list of "incompatibility with MySQL or non-implemented functions", yes, MariaDB generally tries to document noticeable differences between MariaDB and MySQL versions, but omissions are always possible. Please note that MariaDB KB is a community-driven resource, you can edit it yourself if you think it is missing something important.

greenman, could you please add a note somewhere there about the absence of JSON operators in 10.2?

Извините, что на русском, но я смотрю тут преимущественно везде русские имена и фамилии, а с английским у меня плоховато и мне очень трудно переводить на английский язык сложно составленные предложения.

While we do have a significant number of Russian-speaking people in the company, it is still far from majority; but much more importantly, JIRA is very essentially is a community-oriented tool, and the vast majority of our community does not speak Russian (and yes, for the most of them English is not a native language, either). So, while it is naturally an extra effort to write in English, please try to make it as a courtesy to everyone who will have to read your comments. Nobody will hold it against you if it's not perfect.

I've added a specific mention about the JSON operators on https://mariadb.com/kb/en/mariadb/mariadb-vs-mysql-compatibility/#incompatibilities-between-mariadb-102-and-mysql-57

sequelize (equivalent of hibernate for node.js = 200K DL per week) use that as a basis for MySQL/MariaDB, failing with MariaDB.
That would be a nice addition.

we actually want to do it. but it is 1) not a very high priority issue, as it's just a syntax sugar, 2) it would behave differently from MySQL, even if we'll get some syntax sugar, we don't want to have a bad syntax sugar. The point of a syntax sugar is to eliminate as much of the repetitive bolierplate code as possible and to have as simple and naturally looking syntax as possible.