Maciej Malarz

> Currently it seems complicated to resolve environment variable on loading extensions. No, this PR barely exposes accessing env variables to the outside world and does not change any parameters...

I'm sorry but I'm missing the reasons? To me it looks like discussion was unrelated to the proposal itself as it was about how envs are behaving.

> would this already be achievable using either the ParameterBagInterface or ContainerBagInterface? It wouldn't expose processors that way as its logic is defined by `\Symfony\Component\DependencyInjection\Container::getEnv` itself. For instance in our...

FWIW both solutions are BC breaks as they change existing behaviour.

@mdjaman could you please prepare a failing test case and send it as a PR? That will greatly help us identifying your issue. Here you will find an example of...

``` //Playing with new object all children have a null id var_dump($document->getItems()[0]->getChildren()[0]); $objectManager->persist($document); // persisting them and new ids are generated var_dump($document->getItems()[0]->getChildren()[0]); ``` This is expected behaviour - you are...

Ah so they do exist in JSON but are lost when using hydrator. I'm afraid I need to move your issue to the DoctrineModule as this seems to be related...

FWIW ODM-wise it's perfectly fine to have an id before persisting - that will cause an `upsert` operation

> PHPStan or Psalm check for these better. They check them once the spec is written no? It's up to CS to enforce specifying what's inside a traversable. Unless I'm...

We still tend to use both PHPStan and Psalm in all major Doctrine repositories so there's no need for an additional CS rule