Provide the ability to use existing entities in commands for cascading persistence of state aggregate.

[lifinsky]

Description
In aggregates, it's possible to use, for instance, Doctrine entities with cascading persistence, but only for their insertion. Because ObjectManagerInterceptor clear object manager on transaction start.

Example
The only way to correctly save an aggregate with a one-to-many or many-to-many collection of entities is to inject the repository into the command handler of the aggregate or to use a "Before" interceptor that adds entities into the command before passing it to the handler.

[lifinsky]

Current possible solution:
Add interceptor on #[Before(pointcut: CommandHandler::class)], that takes the command with an entity id, then uses the repository to find the entity and returns the same or a different command instance, but with the entity instead of the id.

[dgafka]

Can you provide PR with failing scenario?

[lifinsky]

Hi. I will add code snippets describing the problem. After clear all existing in database entities doctrines are perceived as new and their insertion and binding occurs, instead of just binding to the aggregate

[lifinsky]

@dgafka https://gist.github.com/sushchyk/8ce3c718270f0ac75eb07264f899722a

[dgafka]

So the case is that when we've main Entity (Aggregate Root) like Post and we change it's child Entities Tag, those child Entities won't be saved in database. And this is because we've not have not called ->persist(Tag) on each of them, so Doctrine does not know that they are meant to be saved.

@lifinsky do I understand the problem correctly?

[lifinsky]

No, existing tag was saved but as new record (doctrine allows cascade: ['persist']):

// ObjectManagerInterceptor
            foreach ($managerRegistries as $managerRegistry) {
                /** @var EntityManagerInterface $objectManager */
                foreach ($managerRegistry->getManagers() as $name => $objectManager) {
                    if (! $objectManager->isOpen()) {
                        $managerRegistry->resetManager($name);
                    }
                    if ($this->depthCount === 1) {
                        $objectManager->clear();
                    }
                }
            }

I think we should clear only agregates in unit of work. Entity manager supports clear($entityName = null) - null|string $entityName – if given, only entities of this type will get detached.

[lifinsky]

Currently for this example we should find tag in interceptor with pointcut "before" on CommandHandler (after transaction start)

[dgafka]

So the problem is that we create Tag Entity before outside of Post Aggregate.
As Post Aggregate is created via Command, Unity of Work is cleared, therefore the reference to Tag is also cleared.
This makes Doctrine ORM think this is new Entity, which need to be inserted instead of updated.

@lifinsky is this understanding correct?

[lifinsky]

Problem in using of existing entity, with current functionality of Ecotone we should inject tag repository to aggregate class or use command handler interceptor that find entity by id and fill attribute in command or return new command object (command is ugly with default arguments with null, for example int $tagId = null, Tag $tag = null. We should not clear entities in unit of work before command transaction

[dgafka]

We should not clear entities in unit of work before command transaction

I think, it's fine to set up clearing after, as long as we can clean with each Message, we are good.
Feel free to provide a PR with a test case you mentioned.

[benr77]

I'm running into this same issue. Did anything get sorted in the end as the last comment is quite a while ago and I can't find any related PR. Thanks

[lifinsky]

I'm running into this same issue. Did anything get sorted in the end as the last comment is quite a while ago and I can't find any related PR. Thanks

This issue is actual and not resolved

[lifinsky]

In Ecotone Framework, the ObjectManagerInterceptor clears the Doctrine EntityManager before proceeding with the method invocation. This causes problems when working with Doctrine ORM.

ecotone-dev/packages/Dbal/src/ObjectManager/ObjectManagerInterceptor.php

Line 54 in 601142d

$objectManager->clear();

Possible Solution

Optionally Disabling EntityManager Clearing via Interface for command

We can use a marker interface to specify that a command should not trigger EntityManager::clear() before execution.

---

Solution Steps

1. Create a PreventEntityManagerClear interface.

2. Implement the interface in commands that should not trigger clear().

3. Modify ObjectManagerInterceptor to check for the interface before clearing EntityManager.

---

1. Create the Interface

Define a simple marker interface that commands can implement to prevent EntityManager clearing:

Interface PreventEntityManagerClear {}

This interface does not require any methods — its presence is enough to signal behavior.

---

2. Implement the Interface in Commands

Add the interface to commands that should bypass clear():

readonly class CreatePostCommand implements PreventEntityManagerClear
{
    public function __construct(
        public string $title,
        public Tag $tag
    ) {}
}

Now, Ecotone can detect that this command should not clear the EntityManager.

---

3. Modify ObjectManagerInterceptor

Instead of checking metadata, check whether the command implements PreventEntityManagerClear:

private function shouldSkipClearing(MethodInvocation $methodInvocation): bool
{
    $arguments = $methodInvocation->getArguments();

    if (empty($arguments)) {
        return false;
    }

    $command = $arguments[0]; // The first argument is the command or event object
    return $command instanceof PreventEntityManagerClear;
}

Now, modify the condition before calling clear():

if ($this->depthCount === 1 && !$this->shouldSkipClearing($methodInvocation)) {
    $objectManager->clear();
}

@dgafka We can, of course, use an additional attribute for the command handler itself to avoid adding an infrastructure interface to the domain layer where the command class is located.

[lifinsky]

Attribute name options:

#[PreserveEntityState]
#[SkipEntityManagerReset]
#[DisableEntityManagerClear]

In general, it is always possible to avoid clearing unless inside a consumer, for example...

[lifinsky]

Possible solution but maybe poor performance:

// Detach only aggregates implementing AggregateRoot interface, keeping other entities managed.
$unitOfWork = $entityManager->getUnitOfWork();
foreach ($unitOfWork->getIdentityMap() as $className => $entities) {
    if (is_subclass_of($className, AggregateRoot::class)) {
        foreach ($entities as $entity) {
            $entityManager->detach($entity);
        }
    }
}