feat!: db table for trace data retention policies

[RogerHYang]

resolves #6611
resolves #6594

[axiomofjoy]

Amazing work here Roger.

Main question I have is I'm not grokking the need for the active column if the foreign key relation onto the trace retention policies table is nullable.

[axiomofjoy]

Tricky that we have to manually specify the index name in the migration. Is there a way to use the same auto-generated name?

[RogerHYang]

unfortunately I have not been able to get the batch_op to work without doing it this way

[axiomofjoy]

It looks like the expected behavior is that the env var only takes effect the very first time Phoenix is deployed, and afterward, the default retention period is locked in forever?

[RogerHYang]

yea, that's right. We don't want to change it based on the env var anymore because user could have changed it in the UI already also

[RogerHYang]

Main question I have is I'm not grokking the need for the active column if the foreign key relation onto the trace retention policies table is nullable.

@axiomofjoy This is to disable the sweeper (i.e. keeping it dormant) for people who don't realize this has become a new feature and expect to store their spans forever. In other words, the status quo is no sweeping, so we need to keep it that way.

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[pkg-pr-new]

Open in Stackblitz

npm i https://pkg.pr.new/Arize-ai/phoenix/@arizeai/phoenix-client@6703

commit: 394f665