Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.4
    • Component/s: ORM
    • Security Level: All
    • 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);
      

        Activity

        Show
        Fabio B. Silva added a comment - fixed : https://github.com/doctrine/doctrine2/commit/71a68a5c6fcd49538c3ef2f86d64bcde1958251c
        Hide
        Fabio B. Silva added a comment -

        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.

        Show
        Fabio B. Silva added a comment - 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.
        Hide
        Marco Pivetta added a comment -

        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.

        Show
        Marco Pivetta added a comment - 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.
        Hide
        Christophe Coevoet added a comment -

        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.

        Show
        Christophe Coevoet added a comment - 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.

          People

          • Assignee:
            Fabio B. Silva
            Reporter:
            Fabio B. Silva
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: