[DDC-1955] Support for @EntityListeners Created: 29/Jul/12  Updated: 02/Feb/13  Resolved: 02/Feb/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: None
Fix Version/s: 2.4
Security Level: All

Type: New Feature Priority: Minor
Reporter: Fabio B. Silva Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: None


 Description   

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);


 Comments   
Comment by Christophe Coevoet [ 30/Jul/12 ]

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.

Comment by Marco Pivetta [ 30/Jul/12 ]

Christophe Coevoet 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.

Comment by Fabio B. Silva [ 30/Jul/12 ]

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.

Comment by Fabio B. Silva [ 02/Feb/13 ]

fixed : https://github.com/doctrine/doctrine2/commit/71a68a5c6fcd49538c3ef2f86d64bcde1958251c

Generated at Sun May 26 09:41:56 UTC 2013 using JIRA 5.2.7#850-sha1:b2af0c8dc8537b36121c6a579fabbdf79fc919e5.