You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #272, @caseyjlaw tried to use xds_from_ms to open a sub-table of the MS. This didn't work because xds_from_ms adds some default values (grouping and indexing columns) for opening the MAIN table of an MS. Due to this, we currently use xds_from_table to access sub-tables in our applications.
However, it occurs to me that @caseyjlaw was trying to do the most obvious thing, given the affordance. It could be that split is unnecessary and confusing and that xds_{from,to}_ms should be the interface for dealing with all Measurement Set-like datastores (CASA/zarr/parquet), as well as their sub-tables.
Then, xds_{from,to}_table can be used for general undefined table types, and we could define xds_{from,to}_xxx methods to handle some xxx specification (calibration methods for example).
I had had a similar thought and I am all for it. This would likely be a breaking change, but I think it would be worth it. It means that we can abandon MS-like syntax in xds_{to,from}_table (i.e. don't introduce a MAIN table for no reason) and remove the unintuitive double colon syntax that it necessitated. This functionality can be retained/added in xds_{to,from}_ms to make it "equivalent" with MS access via python-casacore. I think that xds_{to,from}_table should be sufficient for all other use-cases.
In #272, @caseyjlaw tried to use
xds_from_ms
to open a sub-table of the MS. This didn't work becausexds_from_ms
adds some default values (grouping and indexing columns) for opening the MAIN table of an MS. Due to this, we currently usexds_from_table
to access sub-tables in our applications.However, it occurs to me that @caseyjlaw was trying to do the most obvious thing, given the affordance. It could be that split is unnecessary and confusing and that
xds_{from,to}_ms
should be the interface for dealing with all Measurement Set-like datastores (CASA/zarr/parquet), as well as their sub-tables.Then,
xds_{from,to}_table
can be used for general undefined table types, and we could definexds_{from,to}_xxx
methods to handle somexxx
specification (calibration methods for example).Any opinions on this @JSKenyon, @landmanbester, @o-smirnov ?
The text was updated successfully, but these errors were encountered: