Notice: Undefined index

[malas]

When running the command doctrine:fixtures:load we get e PHP notice in the data fixtures line

$entity_manager->flush();

The notice is as follows:

[Symfony\Component\Debug\Exception\ContextErrorException]  
Notice: Undefined index: 00000000008d0501000000004e061b78

The value of index is different every time we run the command. We use one file for the datafixtures, nothing fancy. If we add --no-debug option, the data is loaded correctly.

Has someone also seen this bug? What are the possible reasons of this?

Our composer file:

"require": {
        "php": ">=5.5.9",
        "symfony/symfony": "3.4.*",
        "doctrine/orm": "^2.5",
        "doctrine/doctrine-bundle": "^1.6",
        "doctrine/doctrine-cache-bundle": "^1.2",
        "symfony/swiftmailer-bundle": "^2.3",
        "symfony/monolog-bundle": "^3.0",
        "symfony/polyfill-apcu": "^1.0",
        "sensio/distribution-bundle": "^5.0",
        "sensio/framework-extra-bundle": "^3.0.2",
        "incenteev/composer-parameter-handler": "^2.0",

        "friendsofsymfony/user-bundle": "~2.0@dev",
        "whiteoctober/swiftmailerdbbundle": "^1.0",
        "whiteoctober/tcpdf-bundle": "1.0.*",
        "gedmo/doctrine-extensions": "2.4.*",
        "stof/doctrine-extensions-bundle": "^1.2",
        "doctrine/doctrine-fixtures-bundle": "^2.2",
        "Trsteel/ckeditor-bundle": "^1.10",
        "gregwar/captcha-bundle": "2.*",
        "phpoffice/phpexcel": "^1.8",
        "doctrine/doctrine-migrations-bundle": "^1.2",
        "paragonie/random_compat": "~1.4",
        "malas/php-bounce-handler": "^0.1.0",
        "friendsofsymfony/elastica-bundle": "^4.0",
        "beberlei/DoctrineExtensions": "^1.0",
        "symfony/dom-crawler": "^3.4",
        "vimeo/vimeo-api": "^2.0",
        "squizlabs/php_codesniffer": "^3.2"
    },
    "require-dev": {
        "sensio/generator-bundle": "^3.0",

        "phpunit/phpunit": "^6.0"       
    },

[Ocramius]

This requires an isolated test case to be defined first.

Scenarios that lead to this kind of problem are when the UnitOfWork contains managed entities with un-managed associations somewhere, which is a dirty state.

[malas]

@Ocramius could you give me some links to read about this? Never had a chance to read more about how the UnitOfWork works

[stof]

Can you share your fixtures files to allow reproducing this ?

[malas]

what we have found so far that the fixture file was not changed between the point when it worked and now when it does not. what was changed is:

• some new fields (string, date) added to the entities
• we upgraded vendors:

@stof there you go https://pastebin.com/Kig08rek

[malas]

UPDATE

User entity has a postPersist DoctrineEventListener. The listener creates and persists another entity LeadsPool which has no relations to User entity.

The Notice starts appearing when we remove $entityManager->flush() from the EventListener. This kind of does not make sense because DataFixtures at the end of file has the same call - $entityManager->flush()

[olivermack]

Just as a note: I ran into this issue as well and it disappeared after I started using the EntityManager from the Event Args in favor of the one being constructor-injected by the container.

[alcaeus]

Always use the object manager from the event args, never inject one through the constructor. The event args will always contain the entity manager that triggered the event, while one being injected by the container (most likely) will be the default entity manager which might not always be correct.

[flaushi]

@alcaeus, but in a symfony context, one uses dependency-injected services regularly, which very often themselves got EntitiyManagerInterface injected. So one would have to pass the event's EM into all used service methods, and constructor-based dependency injection would not be feasible anmore?

BTW: I define only one standard connection and entity manager. Does it then make a difference at all which EM I use?

Other scenario: I inject TokenStorageInterface into my event listener to be able to access the user that caused the event. If I want to persist a reference to this user, do I really have to re-find it from the event's EM?? That's possibly a huge performance impact.

Performance: Is it safe to check, e.g. with if($this->em === $args->getEntityManager()) if the two managers are really different instances? For the User / TokenStorage problem, I can just check if the user object in the token fulfils $args->getEventManager()->getUnitOfWork()->isInIdentityMap($userFromToken)?