update notebook to be compatible with newer releases

Author: JoanneBogart

docs/source/tutorial_notebooks/query_gcr_datasets.ipynb

@@ -2,7 +2,7 @@
  "cells": [
   {
    "cell_type": "markdown",
-   "id": "302fd57e-ae4f-4a22-95ad-a69573212a98",
+   "id": "509e7882-7bc8-4180-9634-0be59e4baad7",
    "metadata": {},
    "source": [
     "<div style=\"overflow: hidden;\">\n",
@@ -22,7 +22,7 @@
     "\n",
     "### Before we begin\n",
     "\n",
-    "Currently (November, 2024) the required versions of gcr-catalogs and dataregistry are only available in the `desc-python-bleed` kernel. Make sure you have selected that kernel while running this tutorial.\n",
+    "As of September, 2025, the required versions of gcr-catalogs and dataregistry are  available in the `desc-python` and `desc-python-bleed` kernels. Make sure you have selected one of those kernels while running this tutorial.\n",
     "\n",
     "If you haven't done so already, check out the [getting setup](https://lsstdesc.org/dataregistry/tutorial_setup.html) page from the documentation if you want to run this tutorial interactively."
    ]
@@ -143,10 +143,11 @@
    "outputs": [],
    "source": [
     "from dataregistry import DataRegistry\n",
-    "from dataregistry.schema import DEFAULT_SCHEMA_PRODUCTION\n",
+    "from dataregistry.schema import DEFAULT_NAMESPACE\n",
     "\n",
     "# Establish connection to the production schema\n",
-    "datareg = DataRegistry(schema=DEFAULT_SCHEMA_PRODUCTION)"
+    "prod_schema = DEFAULT_NAMESPACE + \"_production\"\n",
+    "datareg = DataRegistry(schema=prod_schema)"
    ]
   },
   {
@@ -176,10 +177,11 @@
   },
   {
    "cell_type": "markdown",
-   "id": "fa586592-2c2e-428b-b443-33ca26038add",
+   "id": "f08bc754-4fee-44c0-8468-f2d82d2a9283",
    "metadata": {},
    "source": [
-    "That is a list of __all__ columns from __all__ tables, maybe more than we bargained for. Let's restrict it to columns in the `dataset` table."
+    "By default that prints only the columns in the `dataset` table, which is the most interesting for most purposed.\n",
+    "Datasets can be associated with an \"execution\" - in practice this could be a run of a script or a job step in a pipeline.  Here are the columns for that table:"
    ]
   },
   {
@@ -191,16 +193,16 @@
    },
    "outputs": [],
    "source": [
-    "dataset_columns = [col for col in all_columns if col.startswith('dataset.')]\n",
-    "print(dataset_columns)"
+    "execution_columns = datareg.Query.get_all_columns(table=\"execution\")\n",
+    "print(execution_columns)"
    ]
   },
   {
    "cell_type": "markdown",
-   "id": "ad32a278-694a-4364-8dcd-39cdc702039c",
+   "id": "b43623bd-d903-4fab-881c-ec41a81e46b7",
    "metadata": {},
    "source": [
-    "Among the more interesting for our purposes are `name`, `relative_path`, `access_api`, `access_api_configuration` and `location_type`. In the case of catalogs registered with GCRCatalogs, `name` in the data registry is the same name GCRCatalogs uses to refer to it: the basename of the corresponding config file, not including the suffix `.yaml`.  But keep in mind that, unlike GCRCatalog, the dataregistry always respects case in names\n",
+    "Among the more interesting dataset columns for our purposes are `name`, `relative_path`, `access_api`, `access_api_configuration` and `location_type`. In the case of catalogs registered with GCRCatalogs, `name` in the data registry is the same name GCRCatalogs uses to refer to it: the basename of the corresponding config file, not including the suffix `.yaml`.  But keep in mind that, unlike GCRCatalog, the dataregistry always respects case in names\n",
     "\n",
     "Let's look at those properties for the dataset `cosmoDC2_v1.1.4`."
    ]
@@ -294,19 +296,13 @@
    "source": [
     "It all looks pretty much as you would expect, except what happened to the value of `dataset.relative_path`?   That doesn't look like a path. You can see the reason in the catalog's configuration:  it's based on another catalog. Or you can see it in the value for `dataset.location_type`. \"meta_only\" means that the data registry is only storing metadata for the catalog; it is not keeping track of the (indirectly) associated files.  The same thing would happen for a composite catalog: the data registry just stores the catalog's configuration. It doesn't know how to parse it as GCRCatalogs would."
    ]
-  },
-  {
-   "cell_type": "markdown",
-   "id": "5721858e-8e42-4285-9ef0-ead3d780e918",
-   "metadata": {},
-   "source": []
   }
  ],
  "metadata": {
   "kernelspec": {
-   "display_name": "desc-python-bleed",
+   "display_name": "desc-python",
    "language": "python",
-   "name": "desc-python-bleed"
+   "name": "desc-python"
   },
   "language_info": {
    "codemirror_mode": {
@@ -318,7 +314,7 @@
    "name": "python",
    "nbconvert_exporter": "python",
    "pygments_lexer": "ipython3",
-   "version": "3.12.7"
+   "version": "3.12.11"
   }
  },
  "nbformat": 4,