Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accessing original object in lifecycle hook #622

Closed
njeirath opened this issue Jun 22, 2020 · 5 comments
Closed

Accessing original object in lifecycle hook #622

njeirath opened this issue Jun 22, 2020 · 5 comments
Labels
enhancement New feature or request
Milestone

Comments

@njeirath
Copy link

I'd like to conditionally take some actions if certain fields of my entity have been updated and I'm curious if there is any way to gain access to both the original entity as well as the updated entity in the afterUpdate lifecycle hook so I can compare fields to see which were updated?

@B4nan
Copy link
Member

B4nan commented Jun 23, 2020

Currently not, as afterUpdate is executed after the original data is already overridden. We could expose that as a parameter (we could have the whole ChangeSet object there).

Only way I can see now (without accessing private props) is to do the diff yourself, by first saving the state in beforeUpdate.

@B4nan B4nan added the enhancement New feature or request label Jun 23, 2020
@B4nan B4nan added this to the 4.0 milestone Jun 23, 2020
@njeirath
Copy link
Author

That makes sense. Just to add some color to what I'm trying to do in case it's helpful for implementation, I'm basically trying to make the entity observable and only take action on certain kinds of changes:

Say I have a user entity:

export class User {
    static afterCreateObservers: ((e: any) => Promise<void>)[] = []

    id: string
    userName?: string
    lastLogin: Date

    async afterUpdate(): Promise<void> {
        for (const o of User.afterUpdateObservers) {
            await o(this)
        }
    }
}

With an associated EntitySchema object that defines hook the afterUpdate hook.

What I'd like to do is allow an observer to be able to see both the original as well as updated in case it only cares about changes to userName but not lastLogin over the course of the unit of work.

I'll try the approach you recommended and capture the beginning state in a different hook for the time being.

B4nan added a commit that referenced this issue Jun 23, 2020
Lifecycle hooks are now executed the same way as `EntitySubscriber`s, this means that they
will also get the `EventArgs` in the parameters.

`EventArgs` now also optionally contain the `ChangeSet` object, so it is possible to get
the information about what fields actually changed or access the original entity data.

Closes #622
This was referenced Jun 23, 2020
B4nan added a commit that referenced this issue Jun 23, 2020
Lifecycle hooks are now executed the same way as `EntitySubscriber`s, this means that they
will also get the `EventArgs` in the parameters.

`EventArgs` now also optionally contain the `ChangeSet` object, so it is possible to get
the information about what fields actually changed or access the original entity data.

Closes #622
B4nan added a commit that referenced this issue Jun 23, 2020
Lifecycle hooks are now executed the same way as `EntitySubscriber`s, this means that they
will also get the `EventArgs` in the parameters.

`EventArgs` now also optionally contain the `ChangeSet` object, so it is possible to get
the information about what fields actually changed or access the original entity data.

Closes #622
B4nan added a commit that referenced this issue Jun 23, 2020
Lifecycle hooks are now executed the same way as `EntitySubscriber`s, this means that they
will also get the `EventArgs` in the parameters.

`EventArgs` now also optionally contain the `ChangeSet` object, so it is possible to get
the information about what fields actually changed or access the original entity data.

Closes #622
@B4nan
Copy link
Member

B4nan commented Jun 23, 2020

Closing as implemented in v4 via #623, will be part of next alpha.

All hooks will get an EventArgs in the parameter, where you will find changeSet object, with originalEntity instance (keep in mind it is just a POJO of what was retrieved from the database, not an actual instance of entity).

Theoretically it should be even possible to adjust the payload in beforeCreate and beforeUpdate.

@B4nan B4nan closed this as completed Jun 23, 2020
B4nan added a commit that referenced this issue Aug 2, 2020
Lifecycle hooks are now executed the same way as `EntitySubscriber`s, this means that they
will also get the `EventArgs` in the parameters.

`EventArgs` now also optionally contain the `ChangeSet` object, so it is possible to get
the information about what fields actually changed or access the original entity data.

Closes #622
B4nan added a commit that referenced this issue Aug 9, 2020
Lifecycle hooks are now executed the same way as `EntitySubscriber`s, this means that they
will also get the `EventArgs` in the parameters.

`EventArgs` now also optionally contain the `ChangeSet` object, so it is possible to get
the information about what fields actually changed or access the original entity data.

Closes #622
@kennethsato
Copy link

Hello @B4nan .

Is it possible to get originalEntity populated?
I've tried the following lines, but my relationships are unpopulated on originalEntity and populated on entity.

  async afterUpdate(
    eventArgs: EventArgs<Insercao>,
    options: UpdateOptions<any>,
  ): Promise<void> {
    const oldInsercao = eventArgs.changeSet.originalEntity as Insercao;
...

I also tried to eager load the relationship on Insercao Entity definition, but still no success:

  @ManyToOne(() => Comercial, { eager: true })
  comercial: Comercial | null;

Must I find my Comercial to use its property?

@B4nan
Copy link
Member

B4nan commented Mar 14, 2022

originalEntity represents the raw data from database, there are no relations that could be populated, only raw FKs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants