This is just a question regarding the implementation of Postgres Full-Text Search from a year ago. I gather the overall strategy here was to recalculate the tsv columns every time some specific actions occured (row or field is created/updated/deleted).
In the code, I see some Django signals that get dispatched precisely when those actions occur. These are all the relevant signals:
rows_created
rows_updated
rows_deleted
table_created
table_updated
table_deleted
field_created
field_restored
field_updated
field_deleted
I was wondering whether these signals could be relied on to listen for the relevant changes to the data and then trigger the tsv recalculations? Was there a specific implementation detail that required these changes be detected in a different way instead of simply using these signals?
I’m not sure I understand the purpose of the questions because the answers could be slightly different depending on why you’re asking them.
Assuming you are curious about the implementation decisions, my answer to the second question is:
Was there a specific implementation detail that required these changes be detected in a different way instead of simply using these signals?
If you look at the code, you can see that the various SearchHandler methods are not always called immediately after those signals are triggered. They’re not using the same arguments either. This means that we should have added more signals and more arguments to the existing ones to be able to use them. Moreover, since it’s good practice with django not to overuse signals if there are strict dependencies between handlers, we preferred to directly call the SearchHandler from the field/row handler with the needed arguments instead.
In this case, we think it’s the responsibility of the field handler to call the SearchHandler to update (or, better, to start the task that will eventually update) the field values of a table after a field update. In other cases, like updating a public view or informing other users looking at the same view, we delegate the responsibility to signal receivers to notify users about changes.
Coming back to the first question:
I was wondering whether these signals could be relied on to listen for the relevant changes to the data and then trigger the tsv recalculations?
No. You might get a rows_updated signal, but because the tsv_vectors recalculation has not yet been finished, you won’t find the row immediately if you search for that value via the API.