Re: How to ensure a log-entry is created based on state of data in other tables
| От | Steve Midgley |
|---|---|
| Тема | Re: How to ensure a log-entry is created based on state of data in other tables |
| Дата | |
| Msg-id | CAJexoS+s7FcuOTgXXsBDM+xNTUgE0+Tu1+eo54TW_SBsYsTvow@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: How to ensure a log-entry is created based on state of data in other tables (Andreas Joseph Krogh <andreas@visena.com>) |
| Список | 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?SteveYes, they need to be atomic. Either all are DONE and there is an entry in
activity_product_logforproduct_id, or there is no entry inactivity_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 по дате отправления: