This is a working document to clarify proposal option number 2 originally presented in AIP-83 amendment to support classic Airflow authoring style.

Proposal: restore uniqueness but make logical_date nullable and / or optional

Uncontroversial elements

• restore the uniqueness constraint on logical date
• make logical date nullable
• we will not immediately add timetables that don't use logical date

Quetions of controversy

Question 1. For manual runs, should logical date be null by default or only optionally?

Question 2. For asset-triggered runs, should logical date be populated?

And what about dags that are asset-or-schedule?  

Question 3. How to sort in the UI dag runs with no logical date?

Logical date is the default sort field currently.  Start date would be a natural candidate when no logical date.  But it is not populated initially.

One proposal is to add a run_after  field.  This concept already exists in timetables.  But it is not persisted to the dag run record.

Alternatively we could do coalesce(logical_date, start_date, updated_at)

Question 4: Should data_interval_start and data_interval_end be populated?

The question must be answered for both manual runs and asset-triggered.

Question 5: For runs without logical date (or data intervals) what should happen when a user has a template that references them?

Question 6: Implications for run_id

There is still a unique constraint on run_id.  Currently it is generated deterministically from logical date plus run type.  What should we do for runs with no logical date?  How can we support the use case with many runs triggered in close succession such that perhaps even utcnow()  would collide.  What shall we do?