-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Consider never deleting the runs #247
Comments
The current plan is not to completely delete runs, but to archive them. |
I'm not sure archiving is good enough. For data provenance and caching it does not matter whether some run failed or not. Each data piece should have a source execution. It's convenient when all executions are in the same table. |
Not sure I understand. |
This looks similar to what I meant by hiding. What do you think about implementing the feature using labels? We can have a default filter like |
I'm not opposed to using labels for this in principle, but I wouldn't like blocking on its implementation. We can represent this in the UI however we like however. |
I forgot we do not have labels yet. I wonder whether adding labels to the DB schema would be as easy as adding the archived/hidden flag... |
I think we should let user to decide whether to keep the data or not. We might keep the data with a retention period, but I don't think we should keep the data beyond it. Even in managed service, we have to clean up user data if they decide to delete them for privacy reason. |
Resolving. As @hongye-sun pointed out, users may need to delete runs permanently for one reason or another. |
* Add E2E tests for CLI * Add JSON extension to golden files for highlighting * Abstract out JSON expect statements for reuse * Templatize tests
Some features (e.g. the ability to see where a piece of data came from) rely on the retention of runs. It's also extremely useful to be able to see the logs of those runs.
I propose using some mechanism to hide the runs (e.g. setting the
hidden: true
label) instead of deleting the runs altogether.We should carefully gather the feedback about the users' need for run deletion.
The text was updated successfully, but these errors were encountered: