Question

I am using PostgreSQL in my Web API project. I have created Web APIs using .net core. Now I have a situation, where I want to process the inserted or updated data and store the processed data in some other table.

I was thinking to create a trigger for the table that will invoke the REST API created in .net core along with the data and in .net core, I can easily process the data and will insert it into the table I want. The API will be OneWay web service - i.e. fire and forget.

But I was wondering, whether it is a good idea to invoke web service from the database? If it is, then how could I invoke a OneWay Web service from Postgres trigger?

Another approach I found was to use LISTEN/NOTIFY. For this approach, https://shashangka.com/2020/05/17/listen-postgresql-in-asp-net-core/ article seems fine.

I was wondering, which of the approach will be better for my use case and why?

Was it helpful?

Solution

You could write a trigger that calls a web service in PL/Python, but I don't think it is a good idea to do something like that from a trigger:

  • Even though you think that your HTTP communication is one-way, it isn't, since HTTP is implemented on top of the connection-oriented TCP protocol. There is some back-and-forth involved in establishing a TCP connection and sending a request. Now if for example the destination host were unreachable, you would have to wait for a surprisingly long timeout.

  • Database transactions should be as short as possible, so that locks are not held longer than necessary and connection pooling works well (not to mention VACUUM). So any database-external activity of uncertain duration should be avoided during a database transaction. But a trigger always runs in the same transaction as the statement that triggers its execution.

I think the idea with LISTEN/NOTIFY or an approach with a queuing table would be better: the trigger just creates a task, and a worker process picks up the tasks and client-side code sends the HTTP request.

Licensed under: CC-BY-SA with attribution
Not affiliated with dba.stackexchange
scroll top