Question

Let’s say I have these tables/models:

Product
- id
- last_updated_date
- name
- price

User
- id
- name

WishlistItem
- id
- user_id
- product_id

The Product table has a few million records and is being updated automatically each night via a data import (inserting into a new table, dropping the old one). I basically have read-only access to that table/model.

If a product is on a user’s wishlist and the price drops, I’d like to be able to notify that user. What methods can be used to do this?

I have a couple of ideas:

1. Keep track of the Product.last_updated_date in the wishlist model and periodically poll the product table to see if it has been updated. This sounds like a horrible/non-scaleable solution.

2. Some sort of Postgres View or Function that triggers when the Product table is updated? I’m new to postgres so I’m not yet sure if this is even possible.

3. Something amazing that you will suggest that I haven’t thought of 🙂

Any help in the right direction is greatly appreciated!

---

UPDATE:
One idea that came up was caching the current price inside the wishlist entry itself, ie:

WishlistItem
- id
- user_id
- product_id
- price

… then, after the import, I could compare WishlistItem.price with Product.price and notify accordingly. Although it would work, this approach seems a bit wasteful since every WishlistItem for every user will essentially have the same cached copy of the price data and I’ll have to update every list with the new price if there’s an update. I’m not sure there’s a way around it though.

---

UPDATE:
In the end I decided I should probably just be tracking all versions of the data so that I can use standard on update triggers. This also allows me to have a record of all price changes so I can track pricing trends, etc.

Answer 1

You could use an update trigger on Product but it sounds like the Product table is not actually being updated, it is being replaced; if this is the case then there is no update to trigger the trigger so you’ll have to do it the hard way by caching the price in Wishlist (as user247245 notes) and scanning Product for price changes.

If Products is being updated rather than replaced wholesale, then an update trigger could be used to note when a price changes and arrange to have the interested parties notified. The trigger would probably queue up the notifications by inserting them into a separate table (to avoid locking up the Products update) called, say Product_price_changes; then, when the Products update is done, a separate task can compare Product_price_changes to Wishlist, notify the interested users, and finish off by deleting everything in Product_price_changes.

Note that recent versions of PostgreSQL you can restrict an update trigger to only fire when a column changes rather than firing on every row change.