DDC-285: LifeCycleEventArgs constructor/use incomplete #354

New Issue

2026-01-22T12:35:45+01:00

admin commented

2026-01-22 12:35:45 +01:00

Originally created by @doctrinebot on GitHub (Jan 29, 2010).

Jira issue originally created by user kampfcaspar:

LifecycleEventArgs has a field and a getter for the EntityManager, but that field is never set/used. I suppose, this was intended to be used in LifecycleCallbacks, that are currently called void of arguments.

The attached diff corrects the constructor, the constructor calls and calls LifecycleCallbacks with args.

Originally created by @doctrinebot on GitHub (Jan 29, 2010). Jira issue originally created by user kampfcaspar: LifecycleEventArgs has a field and a getter for the EntityManager, but that field is never set/used. I suppose, this was intended to be used in LifecycleCallbacks, that are currently called void of arguments. The attached diff corrects the constructor, the constructor calls and calls LifecycleCallbacks with args.

admin added the Bug label 2026-01-22 12:35:45 +01:00

admin closed this issue

2026-01-22 12:35:47 +01:00

admin commented

2026-01-22 12:35:48 +01:00

@doctrinebot commented on GitHub (Jan 29, 2010):

Comment created by romanb:

Hi.

No, lifecycle callbacks are not supposed to receive arguments. Thats against their nature. Callbacks are placed in the entity itself and are not supposed to introduce coupling to the ORM. Its not even safe to use EntityManager operations in lifecycle callbacks anyway.

As for the lifecycle listeners, it has not yet been decided whether passing the EntityManager to the listeners is a good idea.

@doctrinebot commented on GitHub (Jan 29, 2010): Comment created by romanb: Hi. No, lifecycle callbacks are not supposed to receive arguments. Thats against their nature. Callbacks are placed in the entity itself and are not supposed to introduce coupling to the ORM. Its not even safe to use EntityManager operations in lifecycle callbacks anyway. As for the lifecycle listeners, it has not yet been decided whether passing the EntityManager to the listeners is a good idea.

admin commented

2026-01-22 12:35:48 +01:00

@doctrinebot commented on GitHub (Jan 29, 2010):

Comment created by kampfcaspar:

Sorry, but I was under the impression that the "callbacks" were merely event listeners "attached" to a certain entity. The calling behaviour seen in the source supported my impression.

In order to initiate any (further) ORM action, callbacks & listeners need an anchor into Doctrine. If not the EntityManager, what should it be?

@doctrinebot commented on GitHub (Jan 29, 2010): Comment created by kampfcaspar: Sorry, but I was under the impression that the "callbacks" were merely event listeners "attached" to a certain entity. The calling behaviour seen in the source supported my impression. In order to initiate any (further) ORM action, callbacks & listeners need an anchor into Doctrine. If not the EntityManager, what should it be?

admin commented

2026-01-22 12:35:48 +01:00

@doctrinebot commented on GitHub (Jan 29, 2010):

Comment created by romanb:

The purpose of callbacks is not to initiate ORM actions. The purpose is to initiate business / state actions/changes of the domain object itself. They are not event listeners attached to an entity. Doing that is not a great idea.

Regular event listeners are different but still under construction.

@doctrinebot commented on GitHub (Jan 29, 2010): Comment created by romanb: The purpose of callbacks is not to initiate ORM actions. The purpose is to initiate business / state actions/changes of the domain object itself. They are **not** event listeners attached to an entity. Doing that is not a great idea. Regular event listeners are different but still under construction.

admin commented

2026-01-22 12:35:49 +01:00