Frontend work for viewing and deleting table constraints

[kgodey]

Problem

Users may want to view or delete table constraints.

Proposed solution

We should provide a way to do these actions from the UI following the "Working with Columns" design spec.

This covers:

• Displaying table constraints of all types
• Deleting table constraints of all types

Additional context

• Design issue: Design for editing column properties and table constraints #324
• Design discussion: Working with Columns #436
• Backend issue: CRUD API for table constraints #326
• Backend PR: API for adding and removing table constraints #488
• This issue blocks: Frontend work for adding multi-column unique constraints #531

[raduab]

@kgodey Were exactly should I add the "Table Actions" button?

The design prototype differs from the current implementation:

versus:

[kgodey]

@raduab You can add it either before or after the Filters, Sort, Group fields, thanks for checking.

The design prototype and frontend are somewhat out of sync for a couple of reasons:

• the designs are ahead of the frontend by a few features so they include things the frontend doesn't have yet (like adding records)
• we also had to make some improvised decisions while implementing the frontend because the designs don't cover all states.

[raduab]

@kgodey Thanks for clarifying this for me!

[seancolsen]

@pavish I'm picking up work on this issue and I have a question.

For reference, here's the spec:

As far as I can tell, we don't yet have a Svelte store that holds data about table constraints. I'm wondering if you want to express any opinions about where you'd like me to put the table constraints data within our store structure. The location that seems the most natural to me is to put it in Display (alongside Columns) -- but I'm not so confident in that choice.

On a somewhat related note, we need to decide when to fetch the table constraints data. For performance reasons, it would be nice to wait to fetch it until the user opens the "Table Constraints" modal. But it would simplify the code to fetch it at the beginning (like we do with the columns data). We might even decide to apply some styling based on table constraints, in which case fetching the constraints at the beginning would make sense. (It's not entirely clear to me just from looking at the spec, but we might need to apply a gray background to columns having a primary key table constraint, for example.) Do you have an opinion here?

[pavish]

@seancolsen Constraints are not only required for displaying the modal. We would have more places where we need them. Eg., We might require them to restrict entry into the table and show errors (eg., unique constrains), or when applying filters. We would also have to show separate indication for FKs on the column header. So it would be essential to fetch them at the start.

I think a dedicated store for constraints would be better, similar to Columns and Records.