DDC-1955: Support for @EntityListeners #2468

New Issue

admin · 2026-01-22T13:54:15+01:00

admin commented

2026-01-22 13:54:15 +01:00

Originally created by @doctrinebot on GitHub (Jul 29, 2012).

Jira issue originally created by user @FabioBatSilva:

Support for @EntityListeners

Now subscribers are called for ALL entities, to increase the performance we should allow the configuration listeners for entities that need them.

The @EntityListeners annotation specifies the callback listener classes to be used for an entity or mapped superclass. The @EntityListeners annotation may be applied to an entity class or mapped superclass.

The listenner callbacks methods are annotated by the current callback annotations (@PreUpdate, @PrePersist, etc...)

Example :

/****
 * @EntityListeners({"ContractSubscriber"})
 */
class CompanyContract
{
}

class ContractSubscriber
{
    /****
     * @PrePersist
     */
    public function prePersistHandler(CompanyContract $contract)
    {
        // do something
    }

    /****
     * @PostPersist
     * Most of cases just the entity is needed.
     * as a second parameter LifecycleEventArgs allow access to the entity manager.
     */
    public function postPersistHandler(CompanyContract $contract, LifecycleEventArgs $args)
    {
        // do something
    }
}

$contract = new CompanyFlexContract();
// do something

$em->persist($contract);

Originally created by @doctrinebot on GitHub (Jul 29, 2012). Jira issue originally created by user @FabioBatSilva: Support for @EntityListeners Now subscribers are called for ALL entities, to increase the performance we should allow the configuration listeners for entities that need them. The @EntityListeners annotation specifies the callback listener classes to be used for an entity or mapped superclass. The @EntityListeners annotation may be applied to an entity class or mapped superclass. The listenner callbacks methods are annotated by the current callback annotations (@PreUpdate, @PrePersist, etc...) Example : ``` /**** * @EntityListeners({"ContractSubscriber"}) */ class CompanyContract { } class ContractSubscriber { /**** * @PrePersist */ public function prePersistHandler(CompanyContract $contract) { // do something } /**** * @PostPersist * Most of cases just the entity is needed. * as a second parameter LifecycleEventArgs allow access to the entity manager. */ public function postPersistHandler(CompanyContract $contract, LifecycleEventArgs $args) { // do something } } $contract = new CompanyFlexContract(); // do something $em->persist($contract); ```

admin added the New Feature label 2026-01-22 13:54:15 +01:00

admin closed this issue

2026-01-22 13:54:16 +01:00

admin commented

2026-01-22 13:54:17 +01:00

@doctrinebot commented on GitHub (Jul 30, 2012):

Comment created by stof:

I don't see how this could improve performances much: there is only one event manager, so all listeners would be registered in the same. This means that the event manager would then need to contain some checks to know whether the listener should be called for this entity. This means that it will add overhead for all listeners instead of only in listeners needing to check the entity.

@doctrinebot commented on GitHub (Jul 30, 2012): Comment created by stof: I don't see how this could improve performances much: there is only one event manager, so all listeners would be registered in the same. This means that the event manager would then need to contain some checks to know whether the listener should be called for this entity. This means that it will add overhead for **all** listeners instead of only in listeners needing to check the entity.

admin commented

2026-01-22 13:54:17 +01:00

@doctrinebot commented on GitHub (Jul 30, 2012):

Comment created by @ocramius:

[~stof] I think there's a bit of overhead when calling the event listeners. Btw we could get a huge improvement if the UoW was able to group the operations by entity name. I'm not sure if this already happens.

@doctrinebot commented on GitHub (Jul 30, 2012): Comment created by @ocramius: [~stof] I think there's a bit of overhead when calling the event listeners. Btw we could get a huge improvement if the UoW was able to group the operations by entity name. I'm not sure if this already happens.

admin commented

2026-01-22 13:54:17 +01:00

@doctrinebot commented on GitHub (Jul 30, 2012):

Comment created by @FabioBatSilva:

Hi guys

This feature does not change anything on the current event system, just add another way to handle events.
Actually, the event manager dont filter/group event calls.
So, the listener implementation must filter which entities accept and process.

My idea is build something more simple, like lifecycle callbacks instead of use a event manager.
Grouping the calls in the entity metadata and centralizing the listener instances in a static point.

It should avoid lots of calls from UoW to notify entities without subscribers.

@doctrinebot commented on GitHub (Jul 30, 2012): Comment created by @FabioBatSilva: Hi guys This feature does not change anything on the current event system, just add another way to handle events. Actually, the event manager dont filter/group event calls. So, the listener implementation must filter which entities accept and process. My idea is build something more simple, like lifecycle callbacks instead of use a event manager. Grouping the calls in the entity metadata and centralizing the listener instances in a static point. It should avoid lots of calls from UoW to notify entities without subscribers.

admin commented

2026-01-22 13:54:21 +01:00

@doctrinebot commented on GitHub (Feb 2, 2013):

Comment created by @FabioBatSilva:

fixed : 71a68a5c6f

@doctrinebot commented on GitHub (Feb 2, 2013): Comment created by @FabioBatSilva: fixed : https://github.com/doctrine/doctrine2/commit/71a68a5c6fcd49538c3ef2f86d64bcde1958251c

admin commented

2026-01-22 13:54:21 +01:00

@doctrinebot commented on GitHub (Feb 2, 2013):

Issue was closed with resolution "Fixed"

@doctrinebot commented on GitHub (Feb 2, 2013): Issue was closed with resolution "Fixed"

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#2468