что что?

кажется VO - это что-то близкое к DTO

VO содержат в себе логику это не структуры данных.

я за то, что embeddables - это VO :) а значит знать о паренте ему не нужно, ибо знание о паренте - есть суть связь, что подрузамевает идентификатор, а значит это уже не VO и ембедаблеs, а сущность

поддерживаю полностью

VO содержат в себе логику это не структуры данных.

в java терминологии часто под VO подразумевают DTO

но мы про православные объекты значения

поддерживаю полностью

директория или блоб?))

а вот то, что nullable нельзя сделать embeddables - это мешает...

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

давате напишем свою доктрину!

давате напишем свою доктрину!

давайте нет

с блекджеоком и нуллабл эмбеддабл

ок

убедил

ясно дело проверять, если я знаю, что оно nullable, оно будет проверяться

я старался

ясно дело проверять, если я знаю, что оно nullable, оно будет проверяться

ну вообще это можно запилить

ясно дело проверять, если я знаю, что оно nullable, оно будет проверяться

ну так а смысл? сделай Null реализацию, подставляй вместо нормального объекта, будь счастлив.

достаточно переписать гидратор

ну так а смысл? сделай Null реализацию, подставляй вместо нормального объекта, будь счастлив.

нельзя даже так

ибо у эмбеддабл нет десриминатора

но всё это решается супер-костылём с One2One релейшеном на себя самого

ну так а смысл? сделай Null реализацию, подставляй вместо нормального объекта, будь счастлив.

да, но получу то я MyVO с null во внутреннем состоянии, т.е. VO с невалидным состоянием

так то я бы слелал $this->property ?: new NullVO(), а иначе придется делать поддержку null внутри VO... а если у меня это VO может быть как nullable в одной сущности, так и not null в другой... получается каша

директория или блоб?))

?

?

vote

всем привет, скажите пожалуйста какие есть более гибкие альтернативы формам в SF ?

рисовать руками

ребята, в миграциях можно определить что она dry-run?

bin/console help doctrine:migrations:migrate

И с любой командой можно приписать help и получить описание

а вот то, что nullable нельзя сделать embeddables - это мешает...

с другой стороны... можно практиковать null-object)

но изредка бесит да

да как его практиковать то

разные ситуации есть)

тебе доктрина создала уже в поле твой VO...

И с любой командой можно приписать help и получить описание

уточню: в коде миграции что она запущена как dry-run

тебе доктрина создала уже в поле твой VO...

либо добавить еще одно поле-флаг которое при гидрации будет учитываться, либо храни в json) не сложно ж если структура фиксированная

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

уточню: в коде миграции что она запущена как dry-run

Проверить, появилась ли запись :)

Или вообще изменение

ну ситуация такая: есть большое количество миграций где запись идет через em и их надо абортить если dry-run так как иначе попортится база, dry-run у них нет

вот и надо либо как-то отключить для них его

Проверить, появилась ли запись :)

ага или удалилась :)))

пришел такой программер решил потестить результат миграции и сделал dry-run и пиздец)

ну ситуация такая: есть большое количество миграций где запись идет через em и их надо абортить если dry-run так как иначе попортится база, dry-run у них нет

эм, а нафейхоа тебе в миграциях em?

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

эм, а нафейхоа тебе в миграциях em?

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

тем не менее это не повод использовать em

если такое надо - используй $this->connection в миграции и все на raw sql

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

если такое надо - используй $this->connection в миграции и все на raw sql

хмм

если такое надо - используй $this->connection в миграции и все на raw sql

а оно не выполняется на dry-run ?

код говорит, что нельзя https://github.com/doctrine/migrations/blob/master/lib/Doctrine/DBAL/Migrations/Version.php

я так делаю миграцию с переносом данных preUp вытянул, кинул в переменную, в up поменял структуру, вставил

а оно не выполняется на dry-run ?

не знаю, не проверял)

разве что ивентами обмазаться. Но хз

спасибо, дельные советы!

глянь в файле Андрея 249 и 393 строки

по всей видимости, все, что зарегистрировано через addSql будет работать через dry-run нормально

а вот через connection - будет выполняться

ну там есть слушатель, autoCommitListener, который в dry-run не закоммитит транзакцию

Да. Он их не регистрирует как миграционные изменения.

но не искал, где стартуют

https://www.tomasvotruba.cz/blog/2017/10/16/how-to-use-repository-with-doctrine-as-service-in-symfony/ ктото юзал такой подход к репам? или как вам вцелом)?

то есть dry-run не предотвратит connection execute :(

не предотвратит

ERROR: S client not available

разве что строить костыли через выборку данных через connection и вставку через add sql

нет, connections execute часто нужен если на пхп надо чтото с данными сделать, тут только как то abortIf научиться вызывать

надо будет глянуть, может pr запилить туды

https://www.tomasvotruba.cz/blog/2017/10/16/how-to-use-repository-with-doctrine-as-service-in-symfony/ ктото юзал такой подход к репам? или как вам вцелом)?

Я юзаю такой

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

не знаю, как-то не очень сложно прокинуть руками em или репозиторий

тут я так понимаю авто DI для репозиториев включается

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

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

Есть такой PR принятый https://github.com/doctrine/DoctrineBundle/pull/727 Я пока не вкурил, решает ли он проблему, около решения видимо

Ну... Требует знания за класс, в принципе. Вроде ок

Я юзаю такой

я так понимаю ты доволен)

тут я так понимаю авто DI для репозиториев включается

да именно, чето неоч хочется каждую репу описывать как сервис вручную

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

кстати, make:entity генерирует репу под использование как сервис

Есть такой PR принятый https://github.com/doctrine/DoctrineBundle/pull/727 Я пока не вкурил, решает ли он проблему, около решения видимо

эт чтобы автоматически регались репосы. крутая штука

а если надо чтото заинжектить в саму репу?

autowire ?

аа =)

из минусов как я понимаю оверхед - типо репа - сервис даже если это не нужно?

просто есть же что-то почему такое не сделали по умолчанию

lazy, не?

просто есть же что-то почему такое не сделали по умолчанию

так по умолчанию же при bin/console make:entity

из минусов как я понимаю оверхед - типо репа - сервис даже если это не нужно?

Всмысле лишний ненужный сервис?

я разворачивал еще 4-beta1. надо было из exclude убрать Repository

lazy, не?

это руками нужным прописывать? или оно так по умолчанию?

все как и любые другие сервисы работает

Подскажите, пожалуйста по parameters в четверке.

Best practice это добавлять из в .env?

для dev - да. В prod - нет

Ошибочка, parameters.yml перекочевал в .env, а просто parameters который раньше был в config.yml это совсем другое :)

Best practice это добавлять из в .env?

всякие реквизиты доступа прокидываются из вне через докер как env параметры и получается в приложении этих данных нет ни в каком файлике