JSON_REMOVE меняет порядок ключей?

Question

[psiklop]

Появилась проблема на сайте, есть поле в таблице с JSON, в нем важен порядок ключей.
При построении JSON через php создается порядок. Так было сделано давно и работало долго, проблем не было.
Сейчас JSON_REMOVE в этом поле все портит. Простого решения как я поискал не существует, но решил спросить на всякий случай?

Answer 1

[pantsarny]

Действительно MySQL не сохраняет порядок ключей, а а упорядочивает по алфавиту.
Выполняйте логику удаления элемента на php

Comments

[psiklop]

Ясно, ну что же поделать, перепишем на php.

[Shavadrius]

psiklop,
Вынося за скобки то, что JSON - это, грубо говоря, словарь ключ/значение, где порядок элементов не должен вообще ни на что влиять,
Правильнее будет делать сортировку в той же функции/процедуре, где вызывается JSON_REMOVE. Если не нравится - можно написать свою функцию, да, возможно она будет работать медленнее, но зато со своей логикой.
Еще можно написать триггер на таблицу BEFORE UPDATE на поле JSON и сортировать значение перед изменением там.
Ну или на клиенте изменить логику и перестать зависеть от сортировки в JSON (либо настроить сортировку там).

[psiklop]

Shavadrius, Есть страница в админке откуда порядок приходит уже через $_POST, так было сделано давно, в PHP все работало много лет. Сортировать не выгодно, лишнее место где надо будет застревать, к тому же там ключи на разных языках и могут добавляться.

Единственный нормальный вариант переделать страницу в админке, но тогда изменится сам JSON и надо будет править еще скрипты, которые надо еще вспомнить - пока идеально оставить на PHP.

[Shavadrius]

psiklop, все зависит от того как много операций производится с этими данными и где это чаще всего происходит. Исходя из этого уже можно думать как лучше поступить. Если у вас запись и изменение этого JSON происходит раз в день - то вообще никакой разницы как делать. Я вот вообще не могу представить почему порядок в JSON может быть важен: в UI компонентах нужно сортировать, а не БД и контроллеры мучить.

[psiklop]

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

[psiklop]

Shavadrius, пока жить можно, карточка оффера меняется редко. Оптимизировать конечно надо будет со временем, но там скорее надо будет весь этот JSON раскидать в таблице грамотно. Я что-то не надеюсь, что mysql сильно лучше работает с json, может и ошибаюсь. JSON_REMOVE и прочее я использую потому что так код получается короче и красивее.

Answer 2

[Akina]

есть поле в таблице с JSON, в нем важен порядок ключей.

Бред сивой кобылы. Согласно стандарту, свойства в объекте не имеют такой характеристики как относительный порядок. Они являются ключами коллекции - поэтому, кстати, ещё и не могут дублироваться.

Кстати, сразу понятно, что поле имеет текстовый тип данных, а не JSON. Иначе бы эффект изменения порядка ключей в текстовом представлении JSON давно бы вылез.

Если такой порядок важен - следует использовать массив, а не объект.

Comments

[psiklop]

PHP на ваш стандарт похоже наплевал, все кодируется и раскодируется с сохранением порядка ключей. Вам нужно понимать суть вопроса. А если вам важно и вы считаете в своих силах заниматься научением "как надо правильно" это делать без ненужных эпитетов.

В вашей информации как всегда мало пользы. Хотя если честно я узнал что-то новое про "тип данных JSON" и на том спасибо. И смысл этого типа ? Функции mysql работают на текстовом поле. Он как то иначе хранится и работает быстрее ?

[Дмитрий]

psiklop, а в php вы json из чего собираете?

[Василий Дёмин]

psiklop,

PHP на ваш стандарт похоже наплевал, все кодируется и раскодируется с сохранением порядка ключей.

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

[psiklop]

Дмитрий, страница в админке присылает $_POST - это изначально. Проект разросся. А потом разные мелкие скрипты могут еще что-то делать. Хотя конкретно это значение с парами ключей, где важна сортировка меняется только в админке.

[psiklop]

Василий Дёмин, в мире вообще всё меняется. Но как минимум если не трогать версию PHP врядли в этом проекте это изменится.

[Дмитрий]

psiklop, ну собственно Василий Дёмин уже начал писать собственно в чем прикол что php не надо сортировать ключи - потому что в php все хэш таблицы. и следовательно у вас массив ['a' => 1, 'b'=>2, 'a' =>3] это по факту массив ['a' => 3, 'b'=>2] и сделав json_encode что от первого что от второго - вы получите одинаковый результат. В MySQL немножко не так, и что бы не допустить дублирования ключей - идет сортировка. Ибо согласно стандарту JSON - should be unique

[Василий Дёмин]

psiklop, Дело ваше. Просто это костыль, который может сломаться, и надо иметь это в виду

[Akina]

psiklop,

Функции mysql работают на текстовом поле.

Обрабатывая JSON, MySQL работает с типом данных JSON. Просто "мягкая" система типов данных в MySQL умеет при необходимости выполнять неявное приведение типов, и соответственно интерпретировать текстовую строку как значение типа JSON - вернее, использовать уже JSON, полученный неявным приведением типа. Вот, например, SQL Server подобных вольностей с типами не понимает - как что не то, сразу ошибка.

Он как то иначе хранится и работает быстрее ?

Да. На оба вопроса.

И смысл этого типа ?

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

PHP на ваш стандарт похоже наплевал

Запросто.
Стандарт, кстати, не мой..

[psiklop]

Василий Дёмин, когда сайт переходит на новую версию PHP бывает ломаются даже не "костыли".

[Василий Дёмин]

psiklop, Это не повод использовать костыли, в особенности полагающиеся на детали реализации. Я бы хотел посмотреть на того, кто будет это чинить этот кусок при обновлении версии PHP.

[psiklop]

Дмитрий, я знаю, что в php новый ключ в именном array затрет такой же. Ну это даже не сказать, что логично, я просто представить не могу как может быть по другому. Как это выливается в сортировку не задумывался, но по факту результат сильно разный.

[psiklop]

Василий Дёмин, не волнуйся, я и буду чинить. По факту ты летишь впереди ракеты, предлагаешь чинить уже сейчас, что пока и не сломано и никогда не ломалось и в PHP 8.2 работает как надо.

[psiklop]

Akina, а вот и нет, скорость я тоже приветствую, а не только красоту и тип данных в таблице стараюсь подбирать. К сожалению конкретных примеров от вас не услышал. Погуглил и тоже ничего не нашел. Тип данных JSON ничем не отличается от текстового кроме проверки на корректность. Не факт, может ошибаюсь.

[Akina]

psiklop, ошибаетесь. JSON - это бинарный тип данных. А то, что видно на экране - это реконструированное текстовое представление.

[psiklop]

Василий Дёмин, "костыль" целенаправленно вставили в код из-за лени, зная что это плохо. Тут я сделал так давно, я не преследовал цели решить проблему быстро и плохо, но так вышло. И это замечательно работает еще с php 5.

[Akina]

psiklop,

К сожалению конкретных примеров от вас не услышал.

Пжалста. Смотрим fiddle.
Разница между работой с JSON и работой с тем же значением, но в VARCHAR - налицо.. более чем вдвое.
Заодно видно, что JSON - это бинарные данные.

[psiklop]

Akina, компьютер вообще 0 и 1, а дальше слоями что-то накладывается-накладывается. Мне это "бинарный тип данных" не о чем не говорит на каком он уровне. Нужны конкретные примеры, я web-программист, а не ассемблер.

[Akina]

psiklop,

я web-программист

Тогда разницы нет.

[psiklop]

Akina, ну вот это другой разговор.

[psiklop]

Akina, я просто имел ввиду, что у меня сайт php+mysql, меня интересует выгода относительно этого уровня.

[psiklop]

Akina, что это ? SELECT json_value, CAST(json_value AS CHAR)
нужно будет во всем php коде внести правки ?

[Дмитрий]

psiklop,

Как это выливается в сортировку не задумывался, но по факту результат сильно разный.

Ну сделайте в php

echo json_encode(['key1' => 87, 'key1' => 92, 'key3' => 12, 'key2' => 2, 'key1' => 12]);

И в mysql

SELECT JSON_OBJECT('key1', 87, 'key1', 92, 'key3', 12, 'key2', 2, 'key1', 12);

И посмотрите на значение key1.

[psiklop]

Дмитрий, сделал, но мог не делать, все предсказуемо. PHP перезаписал ключ key1 последним значением. Но при этом сортировку ключей не сделал. Они идут как написаны key1, key3, key2. А mysql сделал.

[psiklop]

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

[Дмитрий]

psiklop, Ну тогда собственно решение вам уже сказали - либо не привязываться к порядку ключей, либо хранить его отдельно, либо не использовать json.

[psiklop]

Akina, потестил скорость x3 и поле в php возвращается. Код менять не нужно. Хорошая тема. Могут все-таки быть какие-то несовместимости в коде не в курсе? если просто взять и поменять в таблицах тип данных? (кроме сортировки ключей)

В mariaDB работает ?
https://runebook.dev/ru/docs/mariadb/json-data-typ...