Reassess partitioned table references

[margaretkennedy]

Here is another example of our inconsistent treatment of classes. Many of the methods in this section are methods on PartitionedTable. Having them separate is consistent with what we do with Table but inconsistent with whatever we recently merged. Having said that, this section is unusually inconsistent in that some articles cram multiple methods together. If nothing else, this is a case that needs to be looked at carefully when figuring out what to do with classes.

[jjbrosnan]

In looking at the sidebar for the partitioned table reference section, I don't see any glaring issues.

The biggest "issue" I have is that partition_by lives there, when that's a constructor method and not a method on a partitioned table itself. I also don't know where else we'd put that, so...

I think we need to assess reference structure as a whole rather than just partitioned tables. Things like:

• What's the standard for documenting classes?
• Should the partitioned table folder live at the same level as the table operations folder?

In my opinion, we should use the "landing pages" as the class reference page

At that point, the only table-related classes that should get a page are tables themselves and the resultant type of a table operation.
Other than that, support classes should also be given a page like IcebergCatalogAdapter, OperationControl, etc.

[jjbrosnan]

Moving this into backlog until we have agreement on how to proceed so we can assess how long it will take.