Seemingly reversed dict for table names

[ahuang11]

import xarray as xr
import xarray_sql as xql


# Open ARCO-ERA5 — a weather dataset with 273 variables since 1940. 
# Turning off dask means we don't have to wait to construct a task graph.
ds = xr.open_zarr(
  'gs://gcp-public-data-arco-era5/ar/full_37-1h-0p25deg-chunk-1.zarr-v3',
  chunks=None,  # Turn dask off
  storage_options={'token': 'anon'}  # Anonymous read from the public GCS bucket — no auth required.
)

ctx = xql.XarrayContext()
# Make sure to pass `chunks`!
ctx.from_dataset('era5', ds, chunks=dict(time=6), table_names={
    ('time', 'latitude', 'longitude'): 'surface',
    ('time', 'level', 'latitude', 'longitude'): 'atmosphere',
})

To my surprise, the table_name is the value instead of the key! I would've expected this:

import xarray as xr
import xarray_sql as xql


# Open ARCO-ERA5 — a weather dataset with 273 variables since 1940. 
# Turning off dask means we don't have to wait to construct a task graph.
ds = xr.open_zarr(
  'gs://gcp-public-data-arco-era5/ar/full_37-1h-0p25deg-chunk-1.zarr-v3',
  chunks=None,  # Turn dask off
  storage_options={'token': 'anon'}  # Anonymous read from the public GCS bucket — no auth required.
)

ctx = xql.XarrayContext()
# Make sure to pass `chunks`!
ctx = ctx.from_dataset('era5', ds, chunks=dict(time=6), table_names={
    'surface': ('time', 'latitude', 'longitude'),
    'atmosphere': ('time', 'level', 'latitude', 'longitude'),
})
ctx.sql("SELECT * FROM era5.surface LIMIT 5")

String -> Tuple

[alxmrs]

The set of the dimension names are, in my mind, the key. That is the group we want to band together. We want to assign it a name, which I see as the value.

I agree, however, that it does seem a bit unconventional. I honestly think that these could go either direction.

@eparkle may want to weigh in here about the reasoning behind this decision or else comment if we could switch it.

[ahuang11]

I feel semi-strongly towards having string keys. I know tuples can be used as keys, but it feels very unconventional and I think we should follow xarray conventions as much as possible to prevent surprises.

For example in https://docs.xarray.dev/en/stable/user-guide/data-structures.html#creating-a-dataset

...
# for real use cases, its good practice to supply array attributes such as
# units, but we won't bother here for the sake of brevity
ds = xr.Dataset(
    {
        "temperature": (["loc", "instrument", "time"], temperature),
        "precipitation": (["loc", "instrument", "time"], precipitation),
    },
    coords={
        "lon": (["loc"], lon),
        "lat": (["loc"], lat),
        "instrument": instruments,
        "time": time,
        "reference_time": reference_time,
    },
)
ds

[ahuang11]

Now that I played around with it, I realized I might have a wrong mental model. I expected each data variable to have its own table, but then I realized it might not make sense that way...

Wrong mental model:

import xarray as xr
import xarray_sql as xql

ds = xr.open_zarr(
  'gs://gcp-public-data-arco-era5/ar/full_37-1h-0p25deg-chunk-1.zarr-v3',
  chunks=None,  # Turn dask off
  storage_options={'token': 'anon'}  # Anonymous read from the public GCS bucket — no auth required.
)
ctx = xql.XarrayContext().from_dataset('era5', ds, chunks={"time": 10}, table_names={("time", "latitude", "longitude"): "2m_dewpoint_temperature"})
ctx.sql('SELECT AVG("time") FROM "era5.2m_dewpoint_temperature"')

[ahuang11]

Okay I think having a xarray -> xql cheat sheet might be helpful, e.g.:

import xarray as xr
import xarray_sql as xql
ds = xr.tutorial.open_dataset("air_temperature")
ds["air_x2"] = ds["air"] * 2

xc = xql.XarrayContext().from_dataset("air", ds, chunks={"time": 10})

# ds["air"].max()
xc.sql("SELECT MAX(air) FROM air")

# ds["air_x2"].mean(["lat", "lon"])
xc.sql("SELECT AVG(air_x2) FROM air GROUP BY time")

However, I still believe that we should reverse the keys/values during assignment so its string: tuple

[JHON12091986]

/claim #182

I'll work on clarifying the difference and inconsistency between ctx.from_dataset and xql.read_xarray.
Will include:

• Analysis of current behavior
• Implementation of consistent API
• Documentation updates
• Tests for both methods

PR ready in 12-24 hours.