SP
А вы желаете зависеть у себя в ядре от реализации? Без проблем. Инверсию зависимостей не любите ?
Не люблю ядра и прочие коры
Size: a a a
2021 February 03
VK
Не люблю ядра и прочие коры
CoreBundle
VK
Туда все что не знаешь куда приткнуть))
AD
CoreBundle
A
Туда все что не знаешь куда приткнуть))
в утилс
SM
CoreBundle ws CommonBundle
D
CoreBundle ws CommonBundle
Websocket ?
2021 February 04
SP
Туда все что не знаешь куда приткнуть))
у меня до сих пор есть AppBundle... вот думаю как написать плагин для псалма который запрещает добавлять туда новые штуки)
КГ
у меня до сих пор есть AppBundle... вот думаю как написать плагин для псалма который запрещает добавлять туда новые штуки)
assert($hashFromAppBundleDir !== <precalculated>) )
KS
Всем привет. Я только начинаю изучать симфони, как и доктрину, посему заранее извиняюсь за возможно тупые вопросы.
Вопроса 2, они связаны.
Первый: как себя ведут отношения сущностей, прописанный только в одной?
Суть в следующем: есть у меня сущность, допустим, Factory, в которой есть свойство furnitureTypes - возможные типы производимой ею мебели (к нему relation и прописываю в аннотации). Соотвественно, у многих фабрик может быть много типов. Есть сущность FurnitureTypes, в которой поле factories мне никуда не уперлось (в аннотациях manyToMany к factory не пишу). Такую связь доктрина довольно хавает, генерит адекватно таблицы, сущности достает, но при попытке сериализации выдает ошибку circular reference. То есть в сущности furnitureTypes внутри Factory есть ссылка на Factory. Я правильно понимаю, что доктрине по барабану, что отношение прописано только в одной сущности?
Если так, то
Второй вопрос: в таком случае отношения manyToMany обречены на circular reference и надо так и так прописывать его обработчик в сериалайзере?
Также извиняюсь за стену текста, хотелось подробно раскрыть тему. В гугле и в доке доктрины/симфони извращений с отношениями, прописанными в одной сущности, не нашел.
Вопроса 2, они связаны.
Первый: как себя ведут отношения сущностей, прописанный только в одной?
Суть в следующем: есть у меня сущность, допустим, Factory, в которой есть свойство furnitureTypes - возможные типы производимой ею мебели (к нему relation и прописываю в аннотации). Соотвественно, у многих фабрик может быть много типов. Есть сущность FurnitureTypes, в которой поле factories мне никуда не уперлось (в аннотациях manyToMany к factory не пишу). Такую связь доктрина довольно хавает, генерит адекватно таблицы, сущности достает, но при попытке сериализации выдает ошибку circular reference. То есть в сущности furnitureTypes внутри Factory есть ссылка на Factory. Я правильно понимаю, что доктрине по барабану, что отношение прописано только в одной сущности?
Если так, то
Второй вопрос: в таком случае отношения manyToMany обречены на circular reference и надо так и так прописывать его обработчик в сериалайзере?
Также извиняюсь за стену текста, хотелось подробно раскрыть тему. В гугле и в доке доктрины/симфони извращений с отношениями, прописанными в одной сущности, не нашел.
SP
Всем привет. Я только начинаю изучать симфони, как и доктрину, посему заранее извиняюсь за возможно тупые вопросы.
Вопроса 2, они связаны.
Первый: как себя ведут отношения сущностей, прописанный только в одной?
Суть в следующем: есть у меня сущность, допустим, Factory, в которой есть свойство furnitureTypes - возможные типы производимой ею мебели (к нему relation и прописываю в аннотации). Соотвественно, у многих фабрик может быть много типов. Есть сущность FurnitureTypes, в которой поле factories мне никуда не уперлось (в аннотациях manyToMany к factory не пишу). Такую связь доктрина довольно хавает, генерит адекватно таблицы, сущности достает, но при попытке сериализации выдает ошибку circular reference. То есть в сущности furnitureTypes внутри Factory есть ссылка на Factory. Я правильно понимаю, что доктрине по барабану, что отношение прописано только в одной сущности?
Если так, то
Второй вопрос: в таком случае отношения manyToMany обречены на circular reference и надо так и так прописывать его обработчик в сериалайзере?
Также извиняюсь за стену текста, хотелось подробно раскрыть тему. В гугле и в доке доктрины/симфони извращений с отношениями, прописанными в одной сущности, не нашел.
Вопроса 2, они связаны.
Первый: как себя ведут отношения сущностей, прописанный только в одной?
Суть в следующем: есть у меня сущность, допустим, Factory, в которой есть свойство furnitureTypes - возможные типы производимой ею мебели (к нему relation и прописываю в аннотации). Соотвественно, у многих фабрик может быть много типов. Есть сущность FurnitureTypes, в которой поле factories мне никуда не уперлось (в аннотациях manyToMany к factory не пишу). Такую связь доктрина довольно хавает, генерит адекватно таблицы, сущности достает, но при попытке сериализации выдает ошибку circular reference. То есть в сущности furnitureTypes внутри Factory есть ссылка на Factory. Я правильно понимаю, что доктрине по барабану, что отношение прописано только в одной сущности?
Если так, то
Второй вопрос: в таком случае отношения manyToMany обречены на circular reference и надо так и так прописывать его обработчик в сериалайзере?
Также извиняюсь за стену текста, хотелось подробно раскрыть тему. В гугле и в доке доктрины/симфони извращений с отношениями, прописанными в одной сущности, не нашел.
> Я правильно понимаю, что доктрине по барабану, что отношение прописано только в одной сущности?
Ну видимо не в одной, раз есть референс обратно.
Ну видимо не в одной, раз есть референс обратно.
SP
и что значит "прописанные в одной сущности"? Валидация мэппинга тебе не говорит что у тебя чет не то?
KS
Не-а, она всем довольна. Сейчас кину скрины классов сущностей.
SP
gist плиз а не срины
SP
а, так а как ты сериализуешь?
SP
просто в доктрине прокси классы.. они содержат ссылку на entity manager... они содержат ссылку на unit of work... а unit of work содержит ссылки на все загруженные энтити и ты получаешь рекурсию
SP
symfony serializer должен это разруливать но я хз умеет ли он это по дефолту
KS
Да, это приблизительно я в дебаге усмотрел. Сериалайзер я свой не писал, чужих не грузил. По идее, дефолтный симфонийный