это понятно, но конкретно в твоей задаче тебе это надо? я не предлагаю тебе везде юзать только sql + php.

В этом и беда гребаная. Мне нужно в одном моменте и первое и второе=\

Связи явно прописаны, но они не всегда нужны в ответе. Но их можно указать, что нужны

можно просто вторым запросом по where id in () еще и потом домэпливать. Тоже неплохой вариант и очень даже гибкий

В этом и беда гребаная. Мне нужно в одном моменте и первое и второе=\

подумай о том что все это можно достать не одним запросом а двумя или тремя

в запросе срез

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

т.е. например 50 сущностей

в запросе срез

срез в первом запросе

во втором ты только для тех штук выбираешь историю

отдельно

и домэпливаешь

но это к каждой сущности из среза нужно дополнить

p.s. год назад я так проект разделял, что бы можно было изолировать таблички в базе по контекстам - было очень даже удобно

т.е. 100 - 150 запросов как с куста

но это к каждой сущности из среза нужно дополнить

можно сделать одним запросом

нет необходимости делать это так как делает та же доктрина

where parent_id IN (ids from your slice)

и потом смапливать все дело между друг-другом?

а это идея

да, это не оч сложно

например подтягивание опциональных смежных таблиц - на SQL это вообще жопа такое собирать

ну то есть для тебя основная ценность - это не меняя запрос подгружать доп данные.

и пофигу что будут те самые +N запросов

я понял за что нелюбят gql на бэке. Это его гребаная гибкость заставляет хуячить всякие костыли

сращивать такое несложно концептуально, но в результате мне нужно 1. Перебрать весь результирующий сэт из 1 запроса, чтобы выудить список ID 2. Запросит доп данные с where in (ids) 3. Перебрать результирующий сэт из п.2 чтобы индексировать его [id => StateDateTime] 4. Перебрать результаты, чтобы сростить данные из п.3 в п.4

Ну ты можешь часть колонок мапить на сущность и доп колонки в массив

А как это сделать?

А как это сделать?

просто в запросе тянешь поле, которого нет в сущности и оно будет в result леежать рядом с сущностью

А сериалайзер не затригеррит подтягивание юзера, если в сущности есть метод getUser, но сам user еще не подтянут?

А сериалайзер не затригеррит подтягивание юзера, если в сущности есть метод getUser, но сам user еще не подтянут?

можно я использую данный комментарий (анонимизированный естественно) в своем докладе как пример почему все это от лукавого?)

конечно)

можно и не анонимно, какая разница?)

если что - it depends. если у тебя сериалайзер работает через методы - то при вызове метода будет затригерена доктриновская прокся

Это вообще все проделки магии, которой я уже нажрался на Yii2 - там она вообще везде. Должен быть метод fetchUser и getUser тогда у сущности, чтобы было все очевидно

Народ, как “правильно” с помощью ентити менеджера обновить существующую запись при on duplicate? я хотел UniqueConstraintException ловить, но тогда получается два запроса

Народ, как “правильно” с помощью ентити менеджера обновить существующую запись при on duplicate? я хотел UniqueConstraintException ловить, но тогда получается два запроса

никак. доктрина не умеет в асперты

наиболее разумный вариант - отказаться в этом месте от ORM и юзать DBAL

прям какой-то национальный день отказа от ORM

27 октября - Международный день народного единства в отказе от ОРМ)

прям какой-то национальный день отказа от ORM

ну что поделать если они делают штуки, которые не подходят под задачи orm

наиболее разумный вариант - отказаться в этом месте от ORM и юзать DBAL

хмм.. проект новый, можно поэкспериментировать. Спасибо за наводку

а какая разница сколько проекту времени?

Ну смотря что делать, риски разные

И никто не подскажет, мне надо просто проанализировать проект и понять какие там страницы есть. Вот в ларавеле - взяль центральный файл с роутами и примерно проверил все что отвечает или нажать можно. Есть ли какой плагинчик для шторма или еще что - чтобы все роуты сифони собрать?

Ну так чтобы прокликать и посмотреть

bin/console debug:router

Ну смотря что делать, риски разные

Если руки из жопы, то хоть новый проект, хоть старый - здесь уже ничего не поможет

Если руки из жопы, то хоть новый проект, хоть старый - здесь уже ничего не поможет

Когда в старом проекте наговнокодишь - никто не уберёт, потому что сложно, и разбираться лень, а в новом - дадут по шапке и скажут как исправить

Гайз, есть тут кто кто переодически посматривает/отслеживает всякие штуки,вне доктрины, которые пилит Марко @Ocramius Скажите мне,пожалуйста, почему: Он зовет инвочные классы, аля QueryFunction через $obj->__invoke($args) а не $someKindOfUsers(); Почему, он вносит __invoke в интерфейс, если это не является частью контракта класса с остальными ньюансами, я как то еще могу мириться :)

на мой вкус - чтобы не ломать глаза странным синтаксисом

Гайз, есть тут кто кто переодически посматривает/отслеживает всякие штуки,вне доктрины, которые пилит Марко @Ocramius Скажите мне,пожалуйста, почему: Он зовет инвочные классы, аля QueryFunction через $obj->__invoke($args) а не $someKindOfUsers(); Почему, он вносит __invoke в интерфейс, если это не является частью контракта класса с остальными ньюансами, я как то еще могу мириться :)

потому что ты можешь всегда сделать grep __invoke(..) по проекту и найти где у тебя это используется

а когда ты делаешь $someVar();

то ты теряешь эту возможность

ну и явное лучше неявного

Плюс если такой объект - свойство другого обьекта, то $this->prop() будет дергать метод prop(), тут или через явный __invoke или через call_user_func нужно дергать

потому что ты можешь всегда сделать grep __invoke(..) по проекту и найти где у тебя это используется

Весьма странная мысль. Кто ж грепом вызовы методов по проекту ищет?

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

Весьма странная мысль. Кто ж грепом вызовы методов по проекту ищет?

чем ищешь?

чем ищешь?

Ctrl+click по методу в шторме

Плюс если такой объект - свойство другого обьекта, то $this->prop() будет дергать метод prop(), тут или через явный __invoke или через call_user_func нужно дергать

ещё можно скобочки написать ($this->prop)();

просто я не вижу юзкейса с QueryFunction как часть какой-то проперти

обычно эта штука, исключительно что бы сделала свое дело где-то в контексте и повысить читаемость

а аргумент про грепы, ну это конечно такое тебе ничего не даст, если ты будешь искать тупо __invoke()

а то же время что так что эдак ты знаешь какой класс ищешь и можешь найти его

но никто так и не сказал про инвок в интерфейсах

А мне интересно, почему у сериалайзера в интерфейсе только методы: serialize и deserialize, а остальных нет)

Например, какие?

denormalize, decode etc

Например, какие?

$arky->ROForAMonth()

Наверное, потому что это не его ответственность?

Наверное, потому что это не его ответственность?

а почему тада у реализации есть эти методы?

Нужны они ей потому что)

Программируй интерфейсами и их не будет)

а почему тада у реализации есть эти методы?

эти методы... и они не приватные ты хотел сказать

а, знач их просто забыли сделать приватными?)0

тогда понятно, спасибо)

Программируй интерфейсами и их не будет)

ты смотри, некотторые этот совет воспринимают слишком буквально и реально создают по интерфейсу (сущность языка, а не понятие публичного интерфейса объекта, поведение объекта, контракт) на каждый класс

ты смотри, некотторые этот совет воспринимают слишком буквально и реально создают по интерфейсу (сущность языка, а не понятие публичного интерфейса объекта, поведение объекта, контракт) на каждый класс

а как надо? Интерфейс на модуль?)

а как надо? Интерфейс на модуль?)

интерфейсы нужны в двух ситуациях: - общие контракт (абстракция) - множество реализаций - интерфейс в одном модуле а реализация в другом (пример - Logger Interface из PSR, общая договоренность между модулями, инверсия зависимостей). Если у тебя появляется модуль Interfaces - то ты не разобрался с темой

На ответственность

интерфейсы нужны в двух ситуациях: - общие контракт (абстракция) - множество реализаций - интерфейс в одном модуле а реализация в другом (пример - Logger Interface из PSR, общая договоренность между модулями, инверсия зависимостей). Если у тебя появляется модуль Interfaces - то ты не разобрался с темой

а как же закрыть своим интерфейсом штуки, что бы они не "менялись"/быть уверенным что не "поменяются"

тут по симфе спрашивать можно?..

На ответственность

слишком широкое понятие, потому не соглашусь

ну всмысле, каждый может спрашивать?..

а как же закрыть своим интерфейсом штуки, что бы они не "менялись"/быть уверенным что не "поменяются"

ты когда в класс публичный метод добавляешь - это уже часть публичного интерфейса и тебе уже надо следить за обратной совместимостью

ну всмысле, каждый может спрашивать?..

да, тип того

но если вопрос гуглится за 5 минут то ты идешь в РО на сутки

Если я в webpack не использую версионирование, то и manifest не нужен?

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

бля, ты ж говорил по симфони вопрос

РО - это что?

ридонли

ну в 4й жеж..

или я уже в РО?

plain object же

но если вопрос гуглится за 5 минут то ты идешь в РО на сутки

Ро должно біть пропорционально тупости вопроса

я тебя не понимать

ну в 4й жеж..

в 4й что?

вебпак..

Ро должно біть пропорционально тупости вопроса

нарисуй табличку

в 4й что?

там замена ассетика на вэбпак

но я хз, у меня вэбпаки отдельно живут