Я видел как бек писали модулями для нгинкса на С

фалькон еще был, помню

вас бросает из стороны в сторону.. с одной сайты визитки, с другой дикий хайлоад в петабайт

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

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

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

так точно нет ничего хуже, чем когда вся говно падает в один nginx, а потом по префиксам хрен пойми как разделять надо а ещё если копролит, то там в пхп недороутинг из кусков сшит

типа того, ага. три server со своими тривиальными локациями куда лучше и поддерживаемее

Всем привет! Не так давно был разговор: https://t.me/symfony_ru/47590 Если кому интересно, вот что имелось ввиду: Пример на скрине выше На выходе bin/console doctrine:schema:update --dump-sql: CREATE TABLE amodel (id SERIAL NOT NULL, c1 VARCHAR(255) DEFAULT '' NOT NULL, PRIMARY KEY(id)); CREATE TABLE bmodel_id (a_model_id INT NOT NULL, id SMALLINT NOT NULL DEFAULT 0, PRIMARY KEY(a_model_id)); CREATE TABLE bmodel (id SMALLINT NOT NULL, a_model_id INT NOT NULL, c1 VARCHAR(255) DEFAULT '' NOT NULL, PRIMARY KEY(a_model_id, id)); CREATE INDEX IDX_E5498A366C13E111 ON bmodel (a_model_id); ALTER TABLE bmodel_id ADD CONSTRAINT FK_bmodel_id_amodel FOREIGN KEY (a_model_id) REFERENCES amodel (id) ON DELETE CASCADE NOT DEFERRABLE INITIALLY IMMEDIATE; CREATE FUNCTION bmodel_next_id(INT) RETURNS SMALLINT LANGUAGE plpgsql AS $$ DECLARE next_id SMALLINT; BEGIN IF ($1 IS NULL) THEN RETURN NULL; END IF; UPDATE bmodel_id SET id = id + 1 WHERE a_model_id = $1 RETURNING id INTO next_id; IF NOT FOUND THEN INSERT INTO bmodel_id VALUES ($1, 1) RETURNING value INTO next_id; END IF; RETURN next_id; END ;$$; CREATE FUNCTION bmodel_before_insert_set_id() RETURNS trigger LANGUAGE plpgsql AS $$ BEGIN NEW.id = bmodel_next_id(NEW.a_model_id); END ;$$; CREATE TRIGGER _000_bmodel_before_insert_set_id BEFORE INSERT ON bmodel FOR EACH ROW EXECUTE PROCEDURE bmodel_before_insert_set_id(); ALTER TABLE bmodel ADD CONSTRAINT FK_E5498A366C13E111 FOREIGN KEY (a_model_id) REFERENCES amodel (id) ON DELETE CASCADE NOT DEFERRABLE INITIALLY IMMEDIATE; Победил лишь тем что переопределил PostgreSQLPlatform(а именно, его getCreateTableSQL). Если кто-то знает лучшее место "воткнуться" со своим SQL - буду рад любым советам. Спасибо!

ужас :)

да вот, тоже переживаю, насколько всё это нормально)

я бы точно такое в прод не потащил :)

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

особо не вчитывался, но почему не set default your_func() ?

чуть меньше сущностей, чуть прозрачнее флоу чем триггер

особо не вчитывался, но почему не set default your_func() ?

потому что функция с параметром - user_id. то есть для вставляемой записи генерится id в пределах одного юзера

а, справедливо

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

ну я ж не собираюсь бизнес логику на DDL пилить) но, с другой стороны, почему не использовать фишки Postgres'а? более того, какие то вещи из уровня движка БД я бы не хотел реализовывать(и тестировать) в коде - мы же не пишем тесты на пхп для БД функций, serial, constrains, etc

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

то есть, это вещи, которые программисту вообще "не видны" должны быть, имхо... чтобы он не смог их сломать... ну а то что SQL говно написать можно, так это волков бояться - в лес не ходить... имхо, на пхп больше вероятность нагадить, если логику БД писать

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

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

так и я про то: тут имхо это плюс, что от программера скрыто - он сломать не сможет. это ж типа SERIAL по смыслу, обычный SERIAL - та же "скрытая магия", и это хорошо, ну с поправкой на ветер)

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

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

пхп масштабируется почти линейно, база - нет

это не понял)

ну в пхп всегда можно серверов докинуть, а сервер бд один

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

а, ну это... ну, тут как бы пхп ровно тот же SQL будет выполнять, так что в данном случае серверу БД легче не будет же

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

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

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

а, ну это... ну, тут как бы пхп ровно тот же SQL будет выполнять, так что в данном случае серверу БД легче не будет же

в пхп можно читать с реплик, кешировать счетчики в более быстрых базах, оптимистичные ключи использовать. база же всегда все "в лоб" будет делать

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

в пхп можно читать с реплик, кешировать счетчики в более быстрых базах, оптимистичные ключи использовать. база же всегда все "в лоб" будет делать

вот это да, интересно. я просто такое разделене в бою не видел... но, ведь и тут, если "упрёмся", не вопрос же убрать триггеры и написать на пхп... а еще лучше) переписать функцию next_id, которая бы уже брала не с таблицы, а с "быстрого кеша" (можно же расширять plpgsql на любом языке)

Всем привет! В 5 версии симфони для PSR7 можно было подключить symfony/psr-http-message-bridge. В 6 версии оно не работает. Если ServerRequestInterface можно подключить через DI с laminas-diactoros, то в контроллере через имплементацию RequestHandlerInterface симфони кидает ошибку: The controller must return a "Symfony\Component\HttpFoundation\Response" object but it returned an object of type Laminas\Diactoros\Response\HtmlResponse Может кто знает, где можно изменить эту зависимость?

Добрый день, столкнулся со следующей проблемой. Есть 2 энтити, которые связаны между собой Many-To-Many. Для одной из этих энтити есть форма Symfony. При создании новой формы (передаче пустой Entity в форму) все корректно отрабатывает и создается. Однако при редактировании уже сущестующей энтити, выбранные чекбоксы не отображаются.

Тупой вопрос. как вот это в комментариях записать в атрибуты, чтобы десериалайзер вложенные объекты понимал? Через атрибуты в данном случае не понимает, тока с @var Tag[] разбирает адекватно. доку всю перевернул уже, не нашол.

Тупой вопрос. как вот это в комментариях записать в атрибуты, чтобы десериалайзер вложенные объекты понимал? Через атрибуты в данном случае не понимает, тока с @var Tag[] разбирает адекватно. доку всю перевернул уже, не нашол.

А он поддерживает аттрибуты?

в доке чето есть про это

ноя чот не понял как )

сериалайзер очень магический компонент, там хер разберешься без поллитры

я бы пошел спросил на гитхабе у них

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

вопрос, кстати, не тупой, а очень хороший, если найдете ответ - не поленитесь, напишите его сюда, очень полезно будет

сериалайзер очень магический компонент, там хер разберешься без поллитры

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

вот это @var не сериалайзер парсит, ща, я вспоминаю

короче, нашел. https://github.com/symfony/symfony/issues/39356

судя по этому багу (мы как раз его собрали и очень весело дебажили), этот функционал лежит где-то в транзитивных зависимостях serializer-pack

судя по названиям (код пока не смотрю)

это лежит где-то в phpdocumentor/reflection-docblock: * phpstan/phpdoc-parser: значит, можно поискать в этих репозиториях упоминания аттрибутов

документации к обоим либам нет 🙂

https://github.com/symfony/symfony/issues/46092 Крч грекас сказал своё фи и послал желающих подальше.

вопрос, кстати, не тупой, а очень хороший, если найдете ответ - не поленитесь, напишите его сюда, очень полезно будет

Поддерживаю

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

я почти всегда уверен, что стоф или грекас завернут даже самую полезную и классную идею. просто потому что

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

А можешь поделиться историей "тупости"?

Я с ним только по одной иссушке знаком

сложно прям конкретный пример привести, это общее впечатление общения с ним за 10 лет

или сколько он там)

или сколько он там)

Это не он любитель трейтов случайно?

Я не погял

Они сказали что аттрибуты не мейнстрим или как?

я почти всегда уверен, что стоф или грекас завернут даже самую полезную и классную идею. просто потому что

Это вообще бич во всех западных конторах больших. Типо зачем что-то делать если можно не делать

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

Ну значит бандл надо написать

Если им можно расширить функциональность

Если нет, ну значит реально фишка без которой можно жить

Хотя я так понял проблема в том что аттрибутами нельзя описать массив энтитей?

ага

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

если есть @var Foo[] - то в в массив сущностей, если нету - в массив массивов

Ну пхп могучий язык

В котором в тайпхинт нельзя написать Tag[]

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

В котором в тайпхинт нельзя написать Tag[]

тоже не пойму почему нельзя сделать узкое подмножество женерик-типов - List<Foo> и Map<Foo, Bar>

покрыло бы 90% юзкейсов среднего пхп-девелопера

хотя без никитоса щас вообще без женериков останемся

А можете, пожалуйста, объяснить мне (наверное тупому)))). Сегодня треть дня ловил почему не находит мапы доктрина. причина была здесь use Doctrine\Orm\Mapping as ORM; ^^^ недоглядел и по табу дополнилось строчными буквами. Но у меня вопрос, тогда получается невалдиный namespace, но ошибки не было. Только доктрина не видела маппинг. Почему не вывалилось ошибки?

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

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

phpstorm) куда уж правильнее)

даже предупреждений не было