Ну правильно, вы же не указываете условие, по которому таблицы должны соединяться.
У вас должно быть условие, в котором упомянуты обе таблицы. Например u1.id=u2.id или что там нужно по бизнес-логике, про которую вы, разумеется ни слова не упомянули в своем вопросе.
Поэтому и в результатах чушь.
Даже если "не симфони единым" (хотя вопрос как бы конкретно про симфони), ответ все равно бесполезный. Потому что вы не понимаете, что делают константы JSON_UNESCAPED_* и приплели их совершенно не к месту.
Видно же, что здесь используется Symfony, с его сериализатором.
И при этом проблема не в самом JSON, а в кривой логике.
При чем здесь голый json_decode? При чем здесь JSON_UNESCAPED_?
Во-первых, так не надо делать. Статическим элементам нечего делать в параметрах.
А по уму надо вообще настроить default значения в базе и совсем выкинуть эти поля из запроса.
Во-вторых, нет смысла делать одноразовую переменную, весь массив можно писать прямо в функцию.
Давайте я вам отвечу на этот дурацкий вопрос, а вы сотрете свой идиотский ответ?
У вас выводится, потому что вы сортируете по кривой дате.
В order by надо писать исходную дату, а не отформатированную.
Не dateformat, а date.
И все прекрасно отсортируется.
Справедливости ради, про уникальность я дописал не сразу, а позже, когда обратил внимание на сам запрос.
Который, как оказалось, никакого отношения к "выполнению запросов MySQL к полю JSON" не имеет.
ситуация, когда пользователь добавил в корзину два товара, потом с телефона добавил еще два, а потом зашел с третьего устройства, и что он в таком случае увидит?
-- это вообще ни о чем.
Если он со всех этих устройств авторизован, то увидит все добавленные товары
если на каком-то не авторизован, то будет добавленные видеть только на этом устройстве.
просто как 2х2
писать какую-то чушь в localStorage с отметкой "id=null" - я вам уже писал выше - нет никакой нужды.
Если пользователь авторизован, то просто отправляем айди товара и количество на сервер, там пишем в базу.
Шерститстость у вас возрастет. Как у Шарика из мультфильма :)
Если вы прочтете ответ Akina, то там нет ни слова про "возрастание". По той простой причине, что никакого возрастания при изменении кодировки с utf8 на utf8mb4 нет и быть не может. Про возрастание писал ниже Sergey В., полную чушь.
Если вы хоть немного почитаете про кодировки, то вам это тоже станет ясно.
Вот видите, вы не понимаете сути вопроса, а беретесь отвечать на него.
И просто сыплете общими фразами про профайлер и Интел, в надежде произвести впечатление эксперта.
Но в итоге выглядите просто глупо :)
У вас должно быть условие, в котором упомянуты обе таблицы. Например u1.id=u2.id или что там нужно по бизнес-логике, про которую вы, разумеется ни слова не упомянули в своем вопросе.
Поэтому и в результатах чушь.