Overview table for events

[ThomasLandauer]

Better late than never - finally delivering what I announced at #8435 (comment) :-)

@SenseException Could you please fill in the two question marks? Or just delete those two rows if the events are not important ;-)

Then please merge this as-is. The plan for this table is to replace the list at https://www.doctrine-project.org/projects/doctrine-orm/en/2.9/reference/events.html#lifecycle-events completely. But I'd like to proceed column by column. And before doing more stupid - character counting ;-) I'd like to see if this does come out nicely on the web page...

Next step would be to link the events (first column) to their respective headers/anchors further down the page, e.g.:

[`prePersist`](#prepersist)

[SenseException]

I have to lookup the missing pieces myself. I'll come back to it.

[ThomasLandauer]

Sure. Can I ask you something in the meantime :-)

At #8435 (comment) you said:

I just realized that the events at the top are representing the Lifecycle Events while the bottom ones are Event Listeners.

And the list at https://www.doctrine-project.org/projects/doctrine-orm/en/2.9/reference/events.html#lifecycle-events says for several events: "This event is not a lifecycle callback."
What does this mean?? If those two ClassMetadata events (and maybe the other non-lifecycle-callbacks) are some special case or rarely used, it's maybe better to exclude them from this table and explain them separately (extra table, list or whatever...)?

[SenseException]

"This event is not a lifecycle callback." What does this mean?

I suppose this is referring to https://www.doctrine-project.org/projects/doctrine-orm/en/2.9/reference/events.html#lifecycle-callbacks where lifecycle callbacks are used in the entity class. Maybe a third "is lifecycle callback" column can mark those who can be used as a lifecycle callback.

If those two ClassMetadata events (and maybe the other non-lifecycle-callbacks) are some special case or rarely used, it's maybe better to exclude them from this table and explain them separately (extra table, list or whatever...)?

I never had a use case where I had to use these ClassMetadata events, but I wouldn't call them special. The table is an overview and doesn't get too much into detail, so I think it's fine to keep those events in there. If there's a need to tell more detailed information about them, then those can be additionally appended as text.

[SenseException]

This is hard to point out. It is triggered when metadata is loaded, which happens in reading methods of the entity manager like find(), getReference() and getPartialReference() when it is loaded for the first time. Of course it is also triggered when $metadataFactory->getMetadataFor() is called directly.

If this table is focused on the entity manager, maybe those three $em methods can be added with the hint of an initial load.

It is also triggered on $em->clear('Foo'), but the argument for clear() is deprecated and will be removed.

[ThomasLandauer]

maybe those three $em methods can be added with the hint of an initial load.

Does "initial" mean (a) for the first time in the current request, or (b) for the first time ever (i.e. until the database structure is changed)? If (a), then there's almost no (?) difference to what I wrote for postLoad (="Loading from database"), since you probably don't load the same entity 20 times in the same request...

[ThomasLandauer]

@SenseException

[greg0ire]

Unassigning from milestone 2.9.6 since I'm trying to release it.

[ThomasLandauer]

Maybe a third "is lifecycle callback" column can mark those who can be used as a lifecycle callback.

Yeah sure! But what I meant is: If some are "lifecycle callbacks", what are the others then? Can you not use them in an entity??

[SenseException]

You can't use them as annotation in an entity, if you mean that. That's right. ORM is using an EventManager where eventlisteners can be registered.

[ThomasLandauer]

OK, I'm starting to understand ;-) So the rule is:

• All events can be registered through the EventManager like this?:

  $entityManager->getEventManager()->addEventListener(array(Events::preUpdate), new MyEventListener());

• "lifecycle callbacks" can also be registered with an annotation in the entity

Right?

[SenseException]

Right, this should summing it up.

[ThomasLandauer]

@SenseException Please merge this as-is - I'd like to see how it looks, and what can already be deleted from the list at https://www.doctrine-project.org/projects/doctrine-orm/en/2.9/reference/events.html#lifecycle-events

About loadClassMetadata (see our unresolved conversation above): There's no way to get all this into the table ;-) So I'd say it should be added to https://www.doctrine-project.org/projects/doctrine-orm/en/2.9/reference/events.html#load-classmetadata-event If I should write it, I'd have to ask you some more questions - so it's probably faster if you write it... :-)

[SenseException]

I guess this should work. :-)

I'd like to have 2 more eyes to look over the table content.

[SenseException]

Thank you @ThomasLandauer