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

From Steve Midgley
Subject Re: How to ensure a log-entry is created based on state of data in other tables
Date
Msg-id CAJexoS+s7FcuOTgXXsBDM+xNTUgE0+Tu1+eo54TW_SBsYsTvow@mail.gmail.com
Whole thread Raw
In response to Re: How to ensure a log-entry is created based on state of data in other tables  (Andreas Joseph Krogh <andreas@visena.com>)
List 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? 

pgsql-sql by date:

Previous
From: Andreas Joseph Krogh
Date:
Subject: Re: How to ensure a log-entry is created based on state of data in other tables
Next
From: "David G. Johnston"
Date:
Subject: Re: How to ensure a log-entry is created based on state of data in other tables