у меня стек на односвязном списке, а у них на битриксе!

у меня стек на односвязном списке, а у них на битриксе!

Ха, хорошая шутка

К слову в пыхе стек реализован на основе двусвязного списка. Но мы нашего слоника не осуждаем

К слову в пыхе стек реализован на основе двусвязного списка. Но мы нашего слоника не осуждаем

ну там на тех же элементах очередь

ну там на тех же элементах очередь

Удобно, правда?

К слову в пыхе стек реализован на основе двусвязного списка. Но мы нашего слоника не осуждаем

xD

Приветствую! Каким способом нынче пользуются, чтобы сохранить массив объектов определенного класса как поле сущности? JSON?

Приветствую! Каким способом нынче пользуются, чтобы сохранить массив объектов определенного класса как поле сущности? JSON?

эм, отношение, не?

или нужен массив?

для массива можно использовать массивы просто)

CREATE TABLE xxxx ( // ... skins SkinType[] NOT NULL DEFAULT [], ); типа такого

Хотелось бы избежать хранения SkinHistoryItem как отдельных сущностей бд. В целом, ChatGPT подсказывает серелизовать их и хранить просто как JSON, как я и подозревал. Но я думал, есть более удобный способ...

ну в теории можно создать тип #[ORM\Column(type: 'SkinType[]')]

но там могут быть проблемы с UoW

надо смотреть как persist на такое реагирует и меняет ли данные в массиве после сохранения

но там могут быть проблемы с UoW

Да не должно быть проблем, кастомный тип делается и как угодно его гонять можно из базы и в базу

Но лучше сделать коллекцию тогда

Да не должно быть проблем, кастомный тип делается и как угодно его гонять можно из базы и в базу

ну у меня были где-то траблы с этим

но сходу не вспомню

А вот такое решение - это зашквар?

А вот такое решение - это зашквар?

ага, но для быстрокода сойдёт

а, ну и у тебя типы не правильные

ну у меня были где-то траблы с этим

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

он вернёт не SkinHistoryItem, а array<array-key, object> скорее всего)

Десериализовать можно или ручками собрать

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

так он композитный же, в этом проблема

вместо json_encode

так он композитный же, в этом проблема

Поэтому и говорю, коллекцию

типа если сделать: $skins[42]->color = 'IDDQD'; то не факт что доктрина увидит чендж этого поля в объекте

Создать свой тип под SkinHistoryСollection и хранить его как json

Но это геморно)

Не сильно, но в целом кодика пописать придется

типа если сделать: $skins[42]->color = 'IDDQD'; то не факт что доктрина увидит чендж этого поля в объекте

и посчитает, что поле (само поле со скинами) не поменялось

как развёрнуто, спасибо 😄 посмотрю как свои типы писать, попробую, если мой метод коленный не прокатит

и посчитает, что поле (само поле со скинами) не поменялось

Резонно, но опять же можно что нить намутить, чтобы объект работал через сеттеры и менял коллекцию которой он принадлежит

как развёрнуто, спасибо 😄 посмотрю как свои типы писать, попробую, если мой метод коленный не прокатит

прокатит

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

можешь вместо json прописать тупо text и сохранять через serialize/deserialize)

но это чревато, любое изменение кода и гг вп

Ну и не забывать сетить обратно, хотя как будто имутабельно)))

Вообще тупо через конструктор собирать и всё)

Оо, в постгрес можно свои типы создавать

прикольнинько

лол)

просто есть подозрение, что только в mysql их нельзя создавать

Да не, просто бд это деталь и привычка всё организовывать в коде

это же как с наркотиками

ну как бы таблица и есть тип просто

кто то может держатся, а кто-то срывается и пишет бизнес логику на триггерах

и в постгре, если не путаю, для каждой таблицы создаётся свой тип в фоне

следовательно, можно просто брать и вкладывать одну таблицу в другую (но это не точно)

ну и массивы тоже есть

Курто, пойду накажу доктрину, чтоб ей сладко не было

следовательно, чтобы создать массив каких-то типов - достаточно создать массив этих типов и в бд)

ну и опять же енамы те же самые

create type some as enum(....);

тоже создание типа

Вообще кстати у меня есть проблема У меня есть лендген, в нём всё разбито на компоненты. Сам лендинг - компонент, он состоит из других компонентов, они тоже из компонентов .... Короче дерево Вот я и думал. а есть какой-нибудь порнаграфических способ вот так хранить компоненты Чтоб я одним запросом мог выдернуть ВСЕХ детей и внуков какого нибудь компонента

ну так хранить их древовидно)

А забирать циклом, да?

но не факт что self reference сработает при создании типа, не проверял

А забирать циклом, да?

нет, запросом одним

получится монга)

да, вот тоже подумал что документоориентированная бд подошла бы лучше

CREATE TYPE component ( name ..., ..., children component[] NOT NULL DEFAULT [], ... );

типа такого

ну и CREATE TABLE components ( id ..., children component[] NOT NULL DEFAULT [], );

но постгря не умеет в синтаксис поиска по массиву

тьфу ты

доктрина)

там синтаксис у постгри обратный

обычно делают hasystack = :needle, а в поиске по массиву постгри наоборот: :needle = ANY("haystack")

т.е. вначале значение, а потом поле где искать

и DQL парсер на таком ёбу даёт)

так что надо извращаться

Да уж проще на чистом, а потом замапить

ну я не пробовал в функцию превратить

типа IN_ARRAY("field", :value)

но подозреваю что доктрина такое тоже не схавает, ей надо чтоб было <field> = <value> в where условиях везде (но это не точно)