Re: How to ensure a log-entry is created based on state of data in other tables

Steve Midgley <science@misuse.org>

From: Steve Midgley <science@misuse.org>
To: Andreas Joseph Krogh <andreas@visena.com>
Cc: pgsql-sql@lists.postgresql.org
Date: 2023-02-09T16:37:35Z
Lists: pgsql-sql
On Thu, Feb 9, 2023 at 8:33 AM Andreas Joseph Krogh <andreas@visena.com>
wrote:

> På torsdag 09. februar 2023 kl. 16:08:16, skrev Steve Midgley <
> science@misuse.org>:
>
> […]
>>
>>
>>
> What is the time window required for "DONE" and "NOT_DONE" to be correct?
> Do they need to be atomic (meaning the time window is effectively 0)? Or
> can the system "notice" recent changes and keep track of done/not done
> after-the-fact? If your time window is > 0, it seems like recurring
> processes could be set up to track DONE / NOT_DONE?
>
> Another totally different way to think about this is to create a view that
> provides answers on DONE and NOT_DONE as computed values based on the
> underlying state of the table at the time the view is queried? That would
> seem to satisfy a time window of 0?
>
> Steve
>
> Yes, they need to be atomic. Either all are DONE and there *is* an entry
> in activity_product_log for product_id, *or* there is no entry in
> activity_product_log.
>
>
>
So, would the view table approach work? So DONE / NOT_DONE is simply
calculated at the time that view is queried? It seems atomic to me,
especially if the query to the table is made with the appropriate
concurrency flags?