:D

вообще, http://docs.sylius.org/en/latest/bundles/SyliusPromotionBundle/index.html

привет, кто то юзал это дело ? https://github.com/IAkumaI/SphinxsearchBundle

привет, кто то юзал это дело ? https://github.com/IAkumaI/SphinxsearchBundle

зачем сфинкс, когда есть эластик?

А зачем эластик, если есть сфинкс?

ну потому что эластик > сфинкса?

А зачем эластик, если есть сфинкс?

года 4 назад я бы тебя поддержал. Но сейчас сфинкс безнадежно отстает

Аксенов это и сам признает, говорит наверстает часть в третьей версии

Шардинг, например

шардинг это полезно, но мне полезны фичи эластики в контексте построения агрегаций данных

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

Ну да, от задач зависит

а еще - возможность юзать эластику с чем угодно

вот это мощно

сфинкс менее гибок в этом плане

А с чем это сфинкс нельзя?

nodejs?

ну точнее можно но то что я находил выглядит ненадежно

а у эластики тупо есть rest api

сидим и не паримся

У сфинкса с 2.3.2 тоже, ну и mysql протокол

сфикнс уже не нужен, уже не интересно

Споры не о чем, сфинкс был в своё время модным, сейчас уже поздно

Завяли помидоры

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

дельта индексы или как там

сейчас это уже не так актуально

Кстати раз такая тема пошла, где-то помимо офсайта приличная дока по эластику есть? Просто на офсайте местами оч плохо

Доки, sylius search bundle

Там правда мясо и он уже в помойке, но как пример эластика пойдёт

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

Как обычно дебажат циркулярные зависимости в контейнере? А то тут уж очень милое исключение вывалилось: [Symfony\Component\DependencyInjection\Exception\ServiceCircularReferenceException] Circular reference detected for service "doctrine.dbal.default_connection", path: "doctrine.dbal.default_connection". Милое - в том смысле, что ничего толком не говорит, т.к. этот сервис нигде в последних изменениях не фигурировал.

хз, походу вариант только смотреть последние изменения конфигов di

в поисках вредного сервиса

Как обычно дебажат циркулярные зависимости в контейнере? А то тут уж очень милое исключение вывалилось: [Symfony\Component\DependencyInjection\Exception\ServiceCircularReferenceException] Circular reference detected for service "doctrine.dbal.default_connection", path: "doctrine.dbal.default_connection". Милое - в том смысле, что ничего толком не говорит, т.к. этот сервис нигде в последних изменениях не фигурировал.

http://api.symfony.com/2.3/Symfony/Component/DependencyInjection/Dumper/GraphvizDumper.html

можно так попробовать

но не уверен что поможет

Спасибо, посмотрю.

https://github.com/matthiasnoback/random-disaster-bundle

?

всем привет

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

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

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

> как то я читал что неймспейсы стоит называть в единственном числе FQCN

нэймспейс это... такая штука...

Services\Broadcaster или Service\Broadcaser

что читается более естественно?

Domain\Catalog\Product vs Entities\Product

Controller\UserController vs Controllers\UserController

мне вот в единичном числе читается легче

ну как и большинству

но не всем (

в yii1 controllers

components

models

в yii1 папки

грустно

а не неймспейсы

и один большой статический класс

а папки пофиг?

папки пофиг)

папки должны описывать твой путь

например....

"я хочу найти сущности отвечающие за каталог"

и ты идешь в "модель предметной области"

окей теперь найдем каталог

папки должны описывать твой путь

а потом руками мапить?(

"каталог"

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

?

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

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

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

в angular styleguide был такой принцп - LIFT.... который я нигде больше не мог нагуглить

When I find my structure is not feeling comfortable, I go back and revisit these LIFT guidelines - Locating our code is easy - Identify code at a glance - Flat structure as long as we can - Try to stay DRY (Don’t Repeat Yourself) or T-DRY

мне дико нравится

>по функционалу а не по типу т.е. не Actions/Controllers

а как тогда?

>по функционалу а не по типу т.е. не Actions/Controllers

у меня сейчас так

src/ Model Catalog Messaging Http Controller EventListener Handler Catalog

ну и т.д.

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

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

src Catalog Model Handler Http Messaging Order Admin User

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

а если мы говорим о симфони мне еще нравится идея убрать директорию src и оставить только app

а у нас будет admins/clients и т.д.)

и ложить все туда

а у нас будет admins/clients и т.д.)

это роли, это не контексты

у нас это неймспейсы)

у меня например в Admin лежат операции, которые должен делать админ

хотя вру я

нет у меня такой штуки