-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
create time filtering for bulk actions table #23560
Changes from all commits
61f40b7
707e547
21ba318
196289a
5c65a33
bf1f747
5ffe3cf
4015656
7b8d04f
f1013a9
b5481c5
997e591
42de3cc
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -4,7 +4,7 @@ | |
from typing_extensions import TypedDict | ||
|
||
from dagster._core.events import DagsterEvent | ||
from dagster._core.execution.backfill import BulkActionStatus, PartitionBackfill | ||
from dagster._core.execution.backfill import BulkActionsFilter, BulkActionStatus, PartitionBackfill | ||
from dagster._core.execution.telemetry import RunTelemetryData | ||
from dagster._core.instance import MayHaveInstanceWeakref, T_DagsterInstance | ||
from dagster._core.snap import ExecutionPlanSnapshot, JobSnapshot | ||
|
@@ -373,6 +373,7 @@ def get_backfills( | |
status: Optional[BulkActionStatus] = None, | ||
cursor: Optional[str] = None, | ||
limit: Optional[int] = None, | ||
filters: Optional[BulkActionsFilter] = None, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we consider changing the order of args? And maybe (in a separate PR) switching callers from using status to using filters? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yeah i think ideally filters would be before status, but there could be callsites that dont use kwargs right? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't see any callsites that don't use kwargs. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We would potentially worry about user code callsites, but There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i'll stack a branch to do this There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. branch for re-ordering #23773 |
||
) -> Sequence[PartitionBackfill]: | ||
"""Get a list of partition backfills.""" | ||
|
||
|
Original file line number | Diff line number | Diff line change | ||
---|---|---|---|---|
|
@@ -38,7 +38,7 @@ | |||
DagsterEventType, | ||||
RunFailureReason, | ||||
) | ||||
from dagster._core.execution.backfill import BulkActionStatus, PartitionBackfill | ||||
from dagster._core.execution.backfill import BulkActionsFilter, BulkActionStatus, PartitionBackfill | ||||
from dagster._core.remote_representation.origin import RemoteJobOrigin | ||||
from dagster._core.snap import ( | ||||
ExecutionPlanSnapshot, | ||||
|
@@ -837,16 +837,27 @@ def get_backfills( | |||
status: Optional[BulkActionStatus] = None, | ||||
cursor: Optional[str] = None, | ||||
limit: Optional[int] = None, | ||||
filters: Optional[BulkActionsFilter] = None, | ||||
) -> Sequence[PartitionBackfill]: | ||||
check.opt_inst_param(status, "status", BulkActionStatus) | ||||
query = db_select([BulkActionsTable.c.body]) | ||||
if status: | ||||
query = db_select([BulkActionsTable.c.body, BulkActionsTable.c.timestamp]) | ||||
if status or (filters and filters.status): | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. unfortunate that we have to do all of this checking around status. I assume we'd have to do a deprecation warning cycle if we wanted to have status filtering be done via the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think so? I don't have a great sense for how often people are manually calling this from user code with the status arg. It's not marked as a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. similarly, should we take this opportunity to make it a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm. Will we need them to render the different tabs in the Runs view? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure if we need the plural statuses, but There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. the Runs page supports filtering for multiple statuses, so i'm updating the BulkActions filter to support multiple statuses in this stacked PR #23772 |
||||
if status and filters and filters.status and status != filters.status: | ||||
raise DagsterInvariantViolationError( | ||||
"Conflicting status filters provided to get_backfills. Choose one of status or BulkActionsFilter.status." | ||||
) | ||||
status = status or (filters.status if filters else None) | ||||
assert status | ||||
query = query.where(BulkActionsTable.c.status == status.value) | ||||
if cursor: | ||||
cursor_query = db_select([BulkActionsTable.c.id]).where( | ||||
BulkActionsTable.c.key == cursor | ||||
) | ||||
query = query.where(BulkActionsTable.c.id < cursor_query) | ||||
if filters and filters.created_after: | ||||
query = query.where(BulkActionsTable.c.timestamp > filters.created_after) | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @prha the time-based filters for the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. more info -
In the graphene layer, I'm doing the same conversion so anything coming from the UI will also get converted to UTC and filtering will be correct https://github.com/dagster-io/dagster/pull/23682/files#diff-61fefa33db2a378b1c50f360e3aa830124007f7bc8f4195005286b529b6e60cdR388 But maybe the right thing to do is to have a custom constructor on There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think either way works... |
||||
if filters and filters.created_before: | ||||
query = query.where(BulkActionsTable.c.timestamp < filters.created_before) | ||||
if limit: | ||||
query = query.limit(limit) | ||||
query = query.order_by(BulkActionsTable.c.id.desc()) | ||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably we will need to expose most of the fields that we currently do on the RunsFilter. Support for those fields is probably out of scope for this PR though.
The question about supporting single vs multiple statuses though will probably depend on the mapping of BulkActionStatus to the various types in the Runs view UI status filters.
We should flag that as a thing we need to figure out (status), as well as some of the other filters (e.g. job_name, tags, etc).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep - to add more context if someone ends up looking at this PR in the future: the main goal of adding this filter now is to remove this block of code https://github.com/dagster-io/dagster/pull/23560/files#diff-c46424223e58f81b69323dee30256f0a38733eac79198279ebbcf5cec19ee16eL461-L492
I noted these things down for the filtering discussion