Create data cube index tables in a schema.

[jheer]

This PR redesigns the data cube indexer to write index tables into a named schema (default 'mosaic'). This allows data cube index tables to be managed in a largely isolated environment and to be reused across users and sessions. Temporary index tables are no longer supported, as temporary tables can not be created within a named schema.

• Breaking: Remove support for temporary tables for data cube index tables.
• Breaking: Remove data cube indexer enabled method, instead use get/set properties.
• Add data cube indexer schema get/set properties.
• Add data cube indexer dropIndexTables() method. This method issues a query to remove the entire data cube index table schema. It should be called if base tables are updated, causing index tables to become stale and inaccurate.
• Update Jupyter widget, remove temp_indexes property and add dataCubeSchema property.
• Update types, method signatures in Coordinator and DataCubeIndexer.
• Update Coordinator API documentation.

[jheer]

@domoritz Can you please spot check the changes to the Jupyter widget? Is the model state initialization (setting the default data cube index table schema) correct? Also, in this context should we prefer camelCase (dataCubeSchema) or underscore_case (data_cube_schema) for model property names?

[domoritz]

It wasn't quite correct. The idea with temp_indexes was that you can set whether indexes should be created as temp indexes or not from the python side.

I updated the code to let you get and set the index schema from the widget. We should prefer data_cube_schema since the variable is accessible from Python (where users interact with it).

[domoritz]

Looks good. I think the idea schema functionality in the python widget is for advanced use cases. Right now, we don't automatically call dropIndexTables which means indexes will not be cleaned up when the user switches where indexes are created. I think that makes sense as default behavior.

[willium]

Exciting to see dropIndexTables()! thanks for adding that.

I believe the most straightforward way for MotherDuck to know that you want some table to live in the browser/WASM (rather than upstream in the warehouse) is by specifying it as a TEMP table. The alternative is mounting a local db. I wonder if this approach will have performance implications when MotherDuck is the server.

[jheer]

We decided to move away from temporary tables in part to also support persistence of index cubes across multiples users and sessions. So that is another aspect to weigh among the trade-offs and design space here.