хз може че поменялось. щас вот как я скинул

в 3.3 версии

наверное, ошибся, всё работает как надо

fields можно убрать - вложенности меньше будет

Разъясните по доктрине. Связь many to many. В доке написано что одна сущность должна быть главной

Почему так? Почему они не равноправны

fields можно убрать - вложенности меньше будет

а ну да, они дефолтные ж. спс

Почему так? Почему они не равноправны

один источник правды?

один источник правды?

может пояснить?

Product Category = many to many. У категории есть много товаров, у товара может быть несколько категорий

Продукт может говорить, что у него есть категория А, а категория А говорит, что она пуста. Кому доверять?

Тому, кто главнее

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

то как один может утверждать одно, а другой другое.

чота пока мозг после AR не могу перестроить

$tovar->addCactegory($category) не означает, что у нас в $category произойдет ->addTovar, если ты руками этого не сделаешь. А может быть еще сложнее, $tovar->addCategory($cat1); $cat2->addTovar($tovar). Что бы не усложнять логику сохранения и выделяют "главную" сущность.

И обычно ее выбор очевиден. В твоем случае главным будет товар, он будет отвечать за связи, так как скорее всего ты будешь делать в коде new Tovar и потом $tovar->addCategory

$tovar->addCactegory($category) не означает, что у нас в $category произойдет ->addTovar, если ты руками этого не сделаешь. А может быть еще сложнее, $tovar->addCategory($cat1); $cat2->addTovar($tovar). Что бы не усложнять логику сохранения и выделяют "главную" сущность.

спасибо, понял

Вы все с какой конфы?)

@phpgeeks

самое интересное то, что человек, который попросил ссыль, в чат так и не зашёл

(маркетинг)

в любом случае больше симфоняш богу симфоняш

?

Приветствую можно ли монтировать postgresql в silex? он ж на компонентах symfony. Не кинете ссылочку?

есть, pdo, dbal и orm. выбирай что нужно и подключай

Orm какой на posgresql?как называется

есть, pdo, dbal и orm. выбирай что нужно и подключай

doctrine orm

doctrine orm

Для построения restfull api с базовой crud стоит ли игра свечь?

Для api сервера

я поднимал такое на doctrine, очень удобно

Для построения restfull api с базовой crud стоит ли игра свечь?

если апи простое, то лучше dbal взять

Спасибо попробую

Для построения restfull api с базовой crud стоит ли игра свечь?

а почему нет? есть целы фреймворки для этого https://api-platform.com/

а почему нет? есть целы фреймворки для этого https://api-platform.com/

Интересненько?

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

согласен на 100%

мы сейчас из простого выросли в очень не простой

не стоит путать запутанный код со сложностью бизнес логики

даже самый простой проект можно сделать очень сложно

осталось 2 месяца до релиза 4й симфони

да и пхп 7.2 в принципе тоже

а я 3.4 жду т.к. она лтс, а заказчик не хочет не-лтс

на 3.4 в любом случае сразу мигрировать надо будет

я планирую начать еще до выхода лтски

на дев версию отмигрирую где-то в середине октября, а там с выходом обновлюсь

а в 4й будет все что в 3.4 и минус депрейкейты. а так Flex, новая структура проекта, Make файлы

флекс мне все равно тут не нужен

не, я дождусь релиза. а то могут еще что-то поменять в RC

про структуру проекта не видел, кстати

не знаю, мне кажется, ломать что-то в RC не тянет на логичное версионирование

до GA они могут делать что угодно)

а почему нет? есть целы фреймворки для этого https://api-platform.com/

Сел изучать сф именно благодаря ему. Надо было проект сделать где главная часть апи. Через неделю выкинул этот бандл к черту

в любом случае, разница между 3.4rc и 3.4 будет на порядок меньше, чем разница между 2.8 и 3.4 :)

А где прочитать про нововведения 4ки? Что-то провафлил

https://symfony.com/blog/category/living-on-the-edge

четверку тут не вижу

фабьен где-то в своих блогах про нее писал

https://symfony.com/blog/symfony-4-a-new-way-to-develop-applications

Да, нашел уже. Спс

Сел изучать сф именно благодаря ему. Надо было проект сделать где главная часть апи. Через неделю выкинул этот бандл к черту

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

С архитектурой там большие проблемы, как я считаю. Все апи описывается вокруг entity. По мне - так правильнее скорее в контроллерах описывать АПИ. CRUD делается магически быстро (правда за 2 дня кодинга у меня теперь не дольше). А как пошла необходимость свои сервисы писать... Там был старый сваггер 2 месяца назад. Пока в итоге поставил nelmio для документации и FOSRest. Первым делом потом заменю Nelmio - тоже какие-то проблемы. Я вообще не понимаю, почему на сф нет решения для автогенерации доки для последнего сваггера.

Хотя сейчас задумался - просто уже время прошло и не так свежо в памяти. ВОзможно основная-то проблема что документация получается не очень. Сваггер использован на 10%. А если надо недокументированное писать - то может и нормально все...

Сел изучать сф именно благодаря ему. Надо было проект сделать где главная часть апи. Через неделю выкинул этот бандл к черту

Почему?

ПОчему сел изучать сф или почему выкинул? Ну скуажем так - у меня не получилось с его помощью начать делать проект нормально. Пересел на nelmio + FOSRest и проект полетел быстро.

Да - вроде все же из-за доки. Мне например надо было сделать передачу post-ом большого массива данных, удобнее такое делать json-объектами. А в доке тогда надо описывать модель / пример json. Как это сделать в api-platform я тупо не нашел - он сам генерит описания функций тупые - типа Создать ресурс - и все

С архитектурой там большие проблемы, как я считаю. Все апи описывается вокруг entity. По мне - так правильнее скорее в контроллерах описывать АПИ. CRUD делается магически быстро (правда за 2 дня кодинга у меня теперь не дольше). А как пошла необходимость свои сервисы писать... Там был старый сваггер 2 месяца назад. Пока в итоге поставил nelmio для документации и FOSRest. Первым делом потом заменю Nelmio - тоже какие-то проблемы. Я вообще не понимаю, почему на сф нет решения для автогенерации доки для последнего сваггера.

ну если у вас дока апи на контроллерах то у вас не REST а RPC, REST оперирует сущностями, поэтому описание доки в сущностих более чем уместно. Если оперируете командами то это кардинально другой поход к API и вы попытались скрестить ежа с ужом, поэтому вам не понравилось. Но это мой дилетанский взгляд. Может я и ошибаюсь.

ну если у вас дока апи на контроллерах то у вас не REST а RPC, REST оперирует сущностями, поэтому описание доки в сущностих более чем уместно. Если оперируете командами то это кардинально другой поход к API и вы попытались скрестить ежа с ужом, поэтому вам не понравилось. Но это мой дилетанский взгляд. Может я и ошибаюсь.

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

ну если у вас дока апи на контроллерах то у вас не REST а RPC, REST оперирует сущностями, поэтому описание доки в сущностих более чем уместно. Если оперируете командами то это кардинально другой поход к API и вы попытались скрестить ежа с ужом, поэтому вам не понравилось. Но это мой дилетанский взгляд. Может я и ошибаюсь.

REST оперирует ресурсами, твои контроллеры и представляют эти самые http ресурсы

более того - поскольку у тебя никогда не будет HATEOAS (потому что ты не гипертекстом обмениваешься с клиентом) у тебя никогда не будет REST

оно как бы и не надо, но не стоит думать как-то категорично

REST оперирует ресурсами, твои контроллеры и представляют эти самые http ресурсы

Сущность и есть ресурс, контроллер это никак не ресурс.

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

RPC - вполне себе годная штука

Сущность и есть ресурс, контроллер это никак не ресурс.

тогда тебе стоит подумать о том зачем нам вообще контроллеры)

ну короч, если ты думаешь что "rest работает с сущностями" то значит у тебя rest=crud

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

тогда тебе стоит подумать о том зачем нам вообще контроллеры)

посути это провайдеры

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

операция идет всегда над сущностями

например PUT /api/messages/123/likes

и это будет более чем валидно

А разве не с сущностями? Зачем тогда http 204?

ну короч, если ты думаешь что "rest работает с сущностями" то значит у тебя rest=crud

crud это всего лишь четыре основные операции над сущьностью

операция идет всегда над сущностями

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

посути это провайдеры

и что такое провайдеры?)

Сущности не всегда равны ресурсам с другой стороны

А разве не с сущностями? Зачем тогда http 204?

для DELETE запросов удобно

например PUT /api/messages/123/likes

ну ты ж всего-то добавил сущность лайк к сообщению

и что такое провайдеры?)

сервисы реализации, контроллер это по сути и есть отдельный сервис

ну ты ж всего-то добавил сущность лайк к сообщению

но это не "настоящая" сущность. это отношение между сущностью и пользователем

можно события или сообщения представлять в качестве http ресурсов