Hacker News Reader

Comment by maxmcd | Hacker News Reader

General question about reacting to database events: It seems like when responding to DB events it would be easy to accidentally create an infinite loop. Is that an issue with this pattern, or is it easy to avoid? Do any of these data subscription tools have safeguards in place to prevent this?

View on HN

This is where command and query (with subscribe) must be neatly separated. An event A launches an updates of the DB, that launches the query part to react, then stop. There is the risk of having an infinite loop, if the event A is launched by the query part, which is very related to the behavior of your app.

Isn't this the case with any interaction between 2 systems? Between a client and server, you can have logic in the client that reacts to a response from the server that triggers another request to the server.

Very true, maybe I'm overthinking it? In my head: If I update full_name from first_name and last_name whenever a user table row changes, if I do this naively I will update the user on every update and trigger a continuous loop of updates.

I have certainly created infinite loops while using React's componentDidUpdate, maybe it's just important to define triggers on single attributes rather than entire database rows.

The ideal case is that the DB can work out the difference in the subscribed query caused by the DB update so that the front end can make changes incrementally and doesn't have to rerender the entire list/table.

Naively it sounds like the halting problem. You would have to verify that no consumer can make a change to the data set you are listening to. You would want to manage yourself when not to respond to an event.

Reply on news.ycombinator.com