[GitHub] [airflow] uranusjr edited a comment on pull request #15397: AIP-39: Foundational TimeTable interface, OnceTimeTable implementation

[GitBox <gi...@apache.org>]

uranusjr edited a comment on pull request #15397:
URL: https://github.com/apache/airflow/pull/15397#issuecomment-823425749


   Alright, I’ve pushed my implementation to all the possible `schedule_interval` variants in use, and this should be ready to be merged on its own. The next step would be to gradually refactor things calling into the DAG class to use the time table API, instead of accessing `schedule_interval` and methods related to it.
   
   I’ve noticed a difficulty during my initial investigation though. There are various places using `DAG.previous_schedule()`, which calculates the DAG’s *previous* run schedule (logically; no guarantee the run actually happened). This is difficult to represent with the time table design, since the time table only schedules the next run (which can be used to replace `DAG.following_schedule()`, in case someone wonders).
   
   The simple solution would be to introduce something like `TimeTable.prev_dagrun_info()` to do it, but I’m wondering, is this really a good way to calculate the “previous run”? I’d imagine I could build something like a linked list of DAG runs, so I can just query when the last scheduled DAG run was from the database, instead of calculating a logical value that does not actually guarantee to reflect reality…


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org