Deleted by

[razzeee]

Can you see this somehow handling a call to delete and additionally adding a userId, that will be linked to another table?

[olivierwilkinson]

Heya,

I'm not sure off-hand, but my gut feeling would be that to do that it may be better to explicitly soft-delete the model using update or updateMany so that you can also set a "deletedBy" field at the same time. Alternatively you could explicitly update the soft-deleted model before or after the delete call.

The soft-deleted models would still be excluded by this library, but yeah I'm not sure how to customize the delete behaviour in a non-global way that is better than using an update.

Would you be able to give me an example of what you would like to achieve? There may be some better solution than I can think of right now.

[razzeee]

The idea is to basically track who (which user) deleted something and when they did this.

I can obviously do it in the service layer, but I feel like moving it down as much as possible would be the safest way to ensure, it's always written.

[sdr0x07b6]

Sorry to interrupt.
That's a design discussion.

What @razzeee is interested in is not the "deletion" but the "event occurrence" of the deletion, right?
And it just happens to be the event of deletion that you want to record now, you might want to record an INSERT event, you might want to record an UPDATE event, i.e., that recording is not the responsibility of the soft delete middleware. What @razzeee wants to accomplish should be sought in the so-called Audit family of middleware.

prisma-soft-delete-middleware is a middleware about logical deletion, and if you ask for functions that have nothing to do with it, prisma-soft-delete-middleware will become something that you don't understand.

At the moment, Prisma itself seems to lack the functionality to do anything too complicated, which is why there seems to be no Audit middleware.
However, it seems to be relatively easy to implement if you just want to transparently store who deleted what and when.
For example,
https://www.prisma.io/docs/concepts/components/prisma-client/middleware/logging-middleware
Couldn't this be accomplished by simply changing the logging in console.log() to "If the action is a physical or logical deletion, save to DB who did it and when"?

[sdr0x07b6]

If we design the table to have a column called deletedBy, we would need a deletedBy column in every table we audit.
If you want to record updates as well, you will also need an updatedBy column. and the same for insertedBy.
And you can only record the most recent update. Because the updatedBy column will be overwritten.

So, instead of thinking in terms of deletedBy columns, you could have an audit table called audit for example, and store prisma.audit.insert({ data: <when, by whom, etc.> }) freely. deletedBy is metadata that is essentially irrelevant to the model.

However, if it is a small application, it is too much of an exaggeration to create a new audit table, so if all you want to record is who deleted the data, you can have a deletedBy column directly.

[razzeee]

Those are valid thought and actually inspire me, but I don't have most of those problems (yet)

Yes, it's audit (or well GDPR) functionality. But as far as I'm aware all our historical tables already have to enforce, that there are no updates. So we always delete and create a new entry. And every table we have, already has an insertedAt column. So we kinda sidestep the problems there.

Anyway, not sure, if a deletedAt or *At wouldn't be metadata too, the only relevant part is the non date part there, but that's probably not a helpful discussion.