Jim Bosch can you explain a bit more what this ticket means please?

This means putting things like numbers of pixels (for images) or numbers of rows (for catalogs) or other summary information into new Registry tables whose schemas would be set by the StorageClass (Michelle Gower has more/better examples, I think).  This is something we've promised from working group days.  It's only relevant for Gen2 deprecation because it might affect schemas in a hard-to-migrate way.

How do these fit in with the proposed changes in the proposed table reorganization?  What criteria determines whether the value goes into a dataset type table as opposed to a StorageClass table?

I believe I included these metadata fields in the table reorganization examples, though they were not the emphasis there, and I was probably lazy there about distinguishing between per-DatasetType and per-StorageClass metadata.  I'd like to try to avoid true per-DatasetType metadata, as it's much easier to imagine how to hang logic for extracting metadata from in-memory datasets off of existing StorageClass mechanisms, and I don't know how we'd solve that problem for DatasetType-specific stuff.

Tim Jenness, I think we should remove this from the schema stability milestone label - while it will involve schema changes when we decide to do it, I think they'll represent an easy migration (just addition of tables, and maybe a column or two) and we don't otherwise need to do it for Gen2 deprecation.

Ok