ну хрен знает, частые штуки запоминаются, а не частые значит не особо нужны

Ну точно спросят зачем сервисам нужен public true

и не сможешь ответить?

Я всегда ставил паблик. Но это не один такой вопрос

я бы тебя уже не взял))

за такой ответ)

#ПОТРАЧЕНО

Ну у меня все сервисы нужны были в контейнере. Их всего около 5ти

Ну у меня все сервисы нужны были в контейнере. Их всего около 5ти

и что, обязательно их public: true делать?

и что, обязательно их public: true делать?

Так они и так тру

But typically, services are accessed using dependency injection. And in this case, those services do not need to be public. So unless you specifically need to access a service directly from the container via $container->get(), the best-practice is to make your services private. In fact, the default services.yaml configuration configures all services to be private by default.

По умолчанию они false

Ну у меня все сервисы нужны были в контейнере. Их всего около 5ти

Я не знаю как ты с симфони 4 года работаешь))

Я не знаю как ты с симфони 4 года работаешь))

Можно 4 года делать круды.

Ну хрен знает

Я не знаю как ты с симфони 4 года работаешь))

Это все равно что сказать как ты 4 года работаешь с php и не знаешь reflection api. Просто не приходилось сталкиваться

Ты ещё и reflection api не знаешь?

(шутка если что)

Ты ещё и reflection api не знаешь?

Я не писал что не знаю

Просто пример с сервисами, это очень важная концепция, которую ты упустил

Я после 2.8 резко пересел на 4.0 ясен пень что я многое из под капота не узнал

Я после 2.8 резко пересел на 4.0 ясен пень что я многое из под капота не узнал

Там небольшая разница

Там небольшая разница

Я после 2.8 резко пересел на 4.0 ясен пень что я многое из под капота не узнал

Я бы посоветовал тогда полистать статьи о том что изменилось с 2.8 + дока если время останется

Там небольшая разница

На самом деле достаточно много изменилось)

В самих концепциях к разработке

В самих концепциях к разработке

Я как-то на конфе сидел по 4й симфе и офигевал

В самих концепциях к разработке

Я про определение сервисов, там небольшая разница. В остальном - может быть, не работал с 2.*

Я про определение сервисов, там небольшая разница. В остальном - может быть, не работал с 2.*

Как раз сервисы очень сильно изменились

С 3 версии стало все сервисами

И автовайринг кругом

В 2.8 нужно было те же контроллеры вручную регать как сервисы

Потом в 4 флекс появился

С формами там переделали

Можете просто про паблик и автовайринг объяснить и я буду счастлив

По FQCN начали задаваться

Открой доку и прочитай

Открой доку и прочитай

Я 2 статьи про паблик прочитал и нихера не понял. Я понимаю только на примере

Ну сочувствую тебе

Ну это тема между di и dic?

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

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

Нормальное такое заявление. 4 года изучает симфони и ничего не знает про сервисы, тебе ли говорить про бесполезность?

Нормальное такое заявление. 4 года изучает симфони и ничего не знает про сервисы, тебе ли говорить про бесполезность?

Кто говорил что я 4 года изучаю симфони? Я работаю с 3 фреймворками

А вместо того чтобы роффлить лучше бы быстро ответили на вопрос

Александр написал. Неужели он с потолка взял?

Я не знаю как ты с симфони 4 года работаешь))

Я не знаю как ты с симфони 4 года работаешь))

Кикнись. Есть разница между 4 года работаешь, и 4 года изучаешь?

Для уровня "знаю сервисы" никакой разницы нет. За 4 года можно было уже все кишки фреймвокра по памяти воспроизвести.

Для уровня "знаю сервисы" никакой разницы нет. За 4 года можно было уже все кишки фреймвокра по памяти воспроизвести.

Закрыли холивар, если это можно так назвать. А то ещё про бандлы в симфони 4 напишу

Ты заврался

Я 4 года работаю с симфой, но все помнить это нереально

Я 4 года работаю с симфой, но все помнить это нереально

Я уже сделал 2 фейспалма

Кикнись. Есть разница между 4 года работаешь, и 4 года изучаешь?

Туть

Сделай еще больше. Может, поумнеешь.

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

А что лично ты принес в это комьюнити?

А что лично ты принес в это комьюнити?

Покрайне мере стараюсь ответить на вопрос

Какой?

Тебе лень постараться и изучить простую тему, почему другие должны тратить свое время, чтобы тебе разжевать?

Какой?

https://github.com/symfony/recipes-contrib/pull/357

А какого хрена я должен тратить время на комьюнити

Ну ты опенсорсер матерый

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

А какого хрена я должен тратить время на комьюнити

У тебя не только проблемы с сервисами, но и с логикой. То есть на тебя должны тратить время, а ты на комьюнити нет?

У тебя не только проблемы с сервисами, но и с логикой. То есть на тебя должны тратить время, а ты на комьюнити нет?

Полечись, честно. Я трачу время на комьюнити, вот только не вижу уже смысла если нет отдачи

@admin прошу закончить обсуждение

Я 2 статьи про паблик прочитал и нихера не понял. Я понимаю только на примере

походу тут дело не в сообществе...

походу тут дело не в сообществе...

Я нашёл уже 3ю и понял про все. Тема закрыта?

Всем привет !

Совет нужен. Я настроил кеш доктрины. Все вроде гуд, попадает в кеш. Теперь стоит задача инвалидации кеша после flush (insert|update) сущности. Может кто-то что-то уже юзал и посоветовать может решение как организовать инвалидацию кеша ?

кеш именно доктриновский, а не отдельным сервисом

я понимаю что делается это через подписку на событие onFlush и еже с ним. Вопрос больше про организацию ключей кеша, чтоб делать по ним быстрый поиск. Сейчас при поступлении запрос на список или конкретный Item сущности генерируется исходя из прилетевших в request данных (там filters, fields и прочие + контекст сериализации) при запросе отдельной сущности, генерируется ключ app.task.{id} 1) я не могу понять как мне потом выдернуть все эти ключи | или конкретный ключ из кеша 2) и не хочется велосипедить, может есть уже отлаженное и проверенное на бою решение по инвалиадации кеша доктрины с возможностью гибкой настройки через конфигурацию yaml Заранее спасибо за ответы

распишите что конкретно нужно

по дефолту, инвалидируйте айтем при его изменнии и все списки

1) получается же что при insert можно валидировать только список, а item-Ы не трогать. верно ? 2) по сути получается, простое решение это - обработчик событий доктрины, в который пробрасывается компонент cache.doctrine и через него я просто буду искать нужные keys и удалять все что нужно. Верно я думаю? 3) можно же при update не просто грохать key в кеше а перезаписывать его значение. или это плохая практика ?

при это операции обновления могут быть и такими UPDATE table SET field="value" WHERE id in (1,2,3,4); то есть тут я должен инвалидировать все keys по всем обновленнм сущностям (если они были в кеше) или сразу обновлять кеш новыми данными (но тут тогда нужно на событие afterFlus - что-то типа). Может еще какие ситуации есть которые я упускаю? из опыта своего просто накидайте, плиз, примеров с плохими / хорошими кейсами, которые приходилось решать

щас кто-то из вас юзает кеш доктрины ?

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

лан понял. все равно спасибо

при это операции обновления могут быть и такими UPDATE table SET field="value" WHERE id in (1,2,3,4); то есть тут я должен инвалидировать все keys по всем обновленнм сущностям (если они были в кеше) или сразу обновлять кеш новыми данными (но тут тогда нужно на событие afterFlus - что-то типа). Может еще какие ситуации есть которые я упускаю? из опыта своего просто накидайте, плиз, примеров с плохими / хорошими кейсами, которые приходилось решать

не уверен что при bulkUpdate будет задействованы стандартные триггеры по инвалидации кеша.