support static data range, rollup priorities

[pjain1]

Adds data_time_range for rollups and the base metrics view as well to declare coverage statically, and changes the same-grain selection tiebreaker to definition order to express rollup priority.

• New data_time_range field on the metrics view and on each rollup. Accepts a rilltime expression (e.g. -1Y to now, -5Y to -1Y, inf). When set, the OLAP min/max probe for that table is skipped and the declared bounds are used for coverage checks.
• Selection tiebreaker: among rollups that pass eligibility and coverage with the same grain, the earlier-defined one wins (was: smallest data range). This is for priority routing across same-grain rollups with overlapping dimensions.

Example

type: metrics_view
version: 1
model: events
timeseries: timestamp
data_time_range: -5Y to now     # base coverage; skips the base min/max probe

dimensions:
...
measures:
...

rollups:
  # Priority 1 — fewest rows for publisher-only queries
  - model: rollup_publisher
    time_grain: day
    data_time_range: -1Y to now
    dimensions: [publisher]
    measures:   [total_impressions]

  # Priority 2 — answers publisher+domain queries the above can't
  - model: rollup_pub_domain
    time_grain: day
    data_time_range: -1Y to now
    dimensions: [publisher, domain]
    measures:   [total_impressions]

  # Historical tier — older queries that the day rollups don't cover
  - model: rollup_monthly_archive
    time_grain: month
    data_time_range: -5Y to -1Y
    dimensions: [publisher, domain]
    measures:   [total_impressions]

A publisher-only query for last week routes to rollup_publisher. Adding a domain filter routes to rollup_pub_domain. A query 2 years back routes to rollup_monthly_archive. A query going over both windows falls back to the base.

Checklist:

• Covered by tests
• Ran it and it works as intended
• Reviewed the diff before requesting a review
• Checked for unhandled edge cases
• Linked the issues it closes
• Checked if the docs need to be updated. If so, create a separate Linear DOCS issue
• Intend to cherry-pick into the release branch
• I'm proud of this work!

[nishantmonu51]

👍 , LGTM.

[begelundmuller]

Any thoughts on using the data_time_range for all time dimensions, not just the default time dimension?

[pjain1]

Good thought but this was primarily to support rollups which are on primary time dimension only as of now. I think it would be too much to support for all secondary time dims unless someone asks for it which would be rare I think.