Model Signals

Does tortoise saves the old values before a save? So I can compare what has been changed.

The context here is I’m trying to create a “application trigger” module, for example :

#When a task is done, all its child tasks should be automatically done too
@Task.bind('after-save')
async def update_child_tasks(self, old_values):
  if old_values.status != self.status:
    if self.status == 'done'
      await Task.filter(mother_task=self).update(status='done')

This is only a small example, there are many other cases where I need triggers like this

Hope it is understood what I’m trying to do, emphasis on trying, I’m accepting ideas on different ways to approach this.

Also it wouldn’t work on batch QuerySet methods, like update or batch_create, if anyone has any idea on how to overcome this that’d be great

[mojimi]

Oh, that was not my question. Why do we need BOTH a before-save and after-save? I don’t see the need? Just after-save, and before-delete?

Don’t worry, English is not my first language either, it’s fine for there to be misunderstandings 😃 Which is why we are having a conversation.

In my code, I use before saves to enforce business rules, but for that I had to change the code so that I can see what has been changed.

I mean, if there are uses for it in SQL there will be here too.

But, at least in my case, without the ability to check before/after (which fields have changed) it wouldn’t be too useful.

[grigi]

@mojimi Unfortunately not. SQLite reports the no of lines filtered, has no syntax to return other data during an update. MySQL reports the no of lines updated, has no syntax to return other data during an update. Postgres eports the no of lines filtered(not updated), and has syntax to return data.

In none of the cases we get the right data (or any data).

The best would be to run two queries in a transaction:

• Filter by parameters to .filter() and by NOT parameters to .update() → This should get you the object that is going to change in the next query
• Do the update

And depending on the database and the configured isolation level, would possibly raise an exception if any race gets detected. So the data would be pretty close to trustworthy, but not guaranteed 100% trustworthy.

Django’s signals is more-or-less what I was talking about 👍