Great, thanks.
I think it's clear that we need to display the child partitions in the treeview. I don't see any other sensible way of enabling those operations without an extremely contrived dialogue design.
Either way we implement this feature, we should test the workflow of how people go through table partitioning with users to get validation on whether or not our decisions make sense for them.
Please now document how those features will be implemented; e.g, for each one:
- View table data: Parent and partition context menu.
- Attach/detach partitions: Parent properties dialogue
...
That will then give us a list of places we'll need to (re)design dialogues and menus etc. for.
It seems like the operations above detail a potential full feature set for table partitioning which is a good starting point. It would be worthwhile to consider what's the minimum we need to include for the first release of table partitioning.
As we get live feedback and release frequently, we can add additional features and fix bugs. If we cut the scope of this, we'll be more confident that we can reach the deadline and deliver user value.
We can determine what should be included by plotting these features within a matrix. Typically user value is on one axis and technical complexity on another, although these can change depending on what your team needs.
We've found that this matrix is really helpful in answering "What's the smallest thing we can build that solves the most important problems?". We typically do this as a team (engineers, designers, and product managers) once we have enough context about user behavior and technical complexity.
I can facilitate a session where we run through this exercise. It typically takes about an hour.