Migration to `@forestadmin/agent` - when a createOverride is called an updateOverride is called immediately after

Help me!
11

Thank you @vince

Of course, we’re considering the update because the updateOverride function gets called on the related collection.

We don’t doublecheck if you’re issueing a unecessary update :slight_smile:
And this specific relation update is unecessary on our side, because we don’t have MongoDB. We have Postgresql, which is a relational DB and the foreign key sits in the “related” table, which have been already created with the parent primary key specified.

In a relational DB perspective, you are just doubling all the DB queries with an additional unecessary update query.

But we deeper dug into this problem on our side. And we can confirm that the http calls from forest to our backend didn’t change.

…So, why we didn’t have this problem before?
Follow me along to find the answer, please :pray:

You (from online forest) send two http calls:

  • che creation to the route POST /forest/BoatContentTranslation
  • the update to the relationship to the route POST /forest/BoatContent/111/relationships/BoatContentTranslations

We used to attach all our audit logs routines to the following http calls (with specific route overrides):

  • create: /BoatContentTranslation
  • update: /BoatContentTranslation/:idBoatContentTranslation

But with the new agent, you are piping all the update http calls into just the one single function updateOverride! Here is the point.

So the final question is:
how do we distingish, with the new agent, the two kinds on interaction (update vs. relation update) from forest?

At the moment, as a workaround, we tried to prevent the unecessary update with a hook on the collection. Here is the code:

contents.addHook('Before', 'Update', (ctx) => { 
    if ('idBoatContent' in ctx.patch && isIdBoatContentUnchanged(ctx))
      ctx.throwForbiddenError('Pretend nothing happened (unnecessary update performed by forest have been prevented)')
  })

But this is the result:
image (68)

That’s not very nice-looking (in a user perspective), actually… :man_shrugging:

And we need an additional query on our side in the isIdBoatContentUnchanged function. Which is required to get the previous data and state if something relevant changed or not… :man_facepalming:

More over, we would need to apply this workaround to all the collections where this problem arises… :face_with_spiral_eyes:

So this is not a feasible solution on our end.

It would be very nice to have something in the context that allows to know the reason for the update (to match the route which the update comes from, in the previous implementation on our end).

Let me know your thoughts, please :pray:

cc @jeffladiray @julien.jolles

Thank you,
Matteo